OpenPath
OpenScape => OpenScape - Mobility (HiPath Wireless, HiPath MobileConnect, IP DECT) => Topic started by: Giuseppe on October 09, 2011, 08:36:33 pm
-
Ciao a tutti, vorrei confrontarmi con quanti di voi hanno cercato di sincronizzare via lan ( IEEE 1588 ) le Bsip1 su una rete Enterasys.
Ecco il risultato da me ottenuto è stato il totale rallentamento della rete, pur configurando multicast, broadcast suppressione e altro, non appena l'antenna comincia a sincronizzarsi,la rete rallenta fino a sembrare una connessione 56K
Qualcuno di voi ha esperienze in merito?
Grazie e buona serata
Giuseppe
-
Che switch Enterasys stai usando ? le funzionalità Layer 3 (L3) sono abilitate o meno in tale switch ? qual'è la topologia di rete (quanti switch, come sono interconnessi) ? che versioni firmware hai su HiPath Cordless IP e nei (o nei) dispositivo Enterasys ? stai utilizzando le VLAN come consigliato nel manuale di servizio (09/2011), vedi allegato ?
Saluti,
Kimera.
-
io non l'ho ancora fatto pero' da manuale le porte dello switch devono essere l2
pero' sono davvero curioso di sapere come va , teniamoci aggiornati
su wiki-siemens per il dect ip c'è una serie di switch su cui è stato testato
2.1.) if the customer use one of the following switches the usage of LAN Sync is possible the following switches are already tested and could be used:
every 24-port PoE Layer2 switch from D-Link; e.g. - D-Link DES-1228P, DES-3028P, DGS-1224TP
every 24-port PoE Layer2 switch from Hewlett Packard (HP ProCurve Series), e.g. - HP ProCurve 2626-PWR
Enterasys Switch B3G124 (1Gbit)
Cisco Catalyst 3560
Cisco Catalyst 2960-48PST-L (48 PoE ports)
Cisco Small Business Pro ESW 500 (remark; all switch ports used for HiPath Cordless IP were configured as "others")
Remark: If the customer use Layer3 switches, the L3 function of the relevant switch ports have to be deactivated.
-
provato oggi in lab con switch huawei 3926 poe
taggate le porte e definite le vlan , problemi zero
-
Ciao, scusate la latitanza.
nel frattempo ho aperto un case ad Enterasys perchè la cosa molto strana è che non appena l'antenna entra in srevizio e quindi la sincronizzazione è attiva, si blocca il management degli switch mentre il routing fra client e server continua a funzionare, la navigazione è ok.
Gli switch sono C5 con funzionalità L3, sono collegati su de switch differenti collegati fra loro mediante trunk tagged, se posiziono lo sniffer vedo una rete 192.168.X.X che fa traffico, questa rete mi dicono essere la rete che si creano le antenne per dialogare e non ha nulla a che fare con quella relamente configurata sulla nostra infrastruttura.
Ciao
Giuseppe
-
Ciao, oggi ho eseguito altri test,
l'antenna IWU che ha indirizzo ip 10.2.X.X è untagged sulla vlan 2 ( 10.2.X.X ) e tagged sulla vlan 50 ( DECT network ), le altre antenne sono bsip1 untagged sulla vlan 50.
Anche cosi purtroppo im management della mia rete si blocca, no telnet no ssh.
Devo secondo voi taggare anche la porta iwu relativa alla rete 10.2.x.x ( vlan 2 )
Ciao
Giuseppe
-
Il Trunk tagged (VLAN Tagged) che hai tra gli Switch comprende la VLAN Id 50 oppure no ? la porta Ethernet dello Switch a cui è connessa la IWU è Tagged con VLAN Id 50 ? com'è esattamente la topologia di rete (chi è connesso a cosa e come: Switch, OSO, IWU e BSIP) ? ...immagino che la VLAN Id 2 sia la VLAN di default (che dovrebbe coincidere con la VLAN Id di default presente negli Switch a cui è connessa la IWU...).
Bisognerebbe capire esattamente la topologia di rete...perchè in base a come sono interconnessi IWU, BSIP ed OSO rispetto all'infrastruttura generale (n Switch in L2/L3) le cose cambiano...infatti, se noti, nel diagramma sopra (puramente indicativo) il secondo Switch è praticamente dedicato alla infrastruttura DECT (cosa che, forse, nel tuo caso non avviene e non è neppure possibile)...in tal senso l'uso delle VLAN (Dominii di Broadcast) va pianificato per bene.
Saluti,
Kimera.
-
Ciao a tutti,
volevo ringraziarvi delle varie info che mi avete dato, sono stato messo sulla gista strada e alla fine è arrivata la soluzione.
Anche dal supporto Enterasys che ha creato alcune policy per permettere una priorità superiore ad un certo traffico alla fine è arrivata la soluzione.
Ora però mi sorge un dubbio.
Se analizziamo il traffico fra antenne, il famoso PTPV1 si scopre che il traffico è diretto al 255.255.255.255, ora in tutti i manuali e documenti possibili viene indicato che il PTPV1 è MULTICAST non BROADCAST, perchè Siemens deve cambiare le regole????
Quanti di voi hanno attivato la sync over lan?
Grazie e buon lavoro
Giuseppe
-
Se, come è indicato (non molto chiaramente) nella manualistica di servizio, il traffico PTP è gestito in Multicast (come da IEEE1588-2008 / PTPv2) allora tutto il traffico da/per la BSIP-Only (Master Clock) dovrebbe obbligatoriamente andare ad usare il range di IP Addresses ad esso dedicato, ovvero una Classe D da 224.0.0.0/4 fino a 239.255.255.255 e non il "limited broadcast" Address di Classe E 255.255.255.255...
Non è che c'è lo zampino di una PSR per attivare il PTP (Sincronizzazione over LAN) ?
Simpatico il Precious Time Protocol 8-O
Saluti,
Kimera.
-
Ma nella versione 1.3.2, quella che stiamo utilizzando, il PTP sembra attivo, ma il PTP V1 ! e comunque non parla correttamente secondo me ( broadcast e non multicast ).
Comunque stamattina ho scoperto che il simpatico sistema, se non opportunamente configurato con vlan, sia lo sincronizziamo via lan sia lo sincronizziamo via etere, ha la capacità di far crollare una intera rete, sia essa formata da Enterasys, sia da altri vendor, lui però continua a funzionare tranquillamente....
Come lo si spiega ad un cliente che dalle 08:00 del mattino sta imprecando che basta scollegare le antenne e tutto dopo circa 30 minuti ritorna a funzionare???
Mi piacerebbe che il problema emergesse in Siemens, quanti di voi hanno attivato la sync over lan e hanno riscontrato problemi?
Grazie e buona giornata
Giuseppe
-
Scusa...HiPath Cordless IP V1 R cosa ? ...V1 R1.3.2 ? ...stai scherzando vero ?...ma se Siemens se ne è uscita qualche giorno fa con V1 R4.0.0 (prima in FT ora dovrebbe essere già GA)...che Io sappia non esiste alcuna V1 R1.3.2 ...a meno che non sia una release ad-hoc per il tuo sistema...e, anche se lo fosse, risalirebbe almeno al 2009 (tra V1 R1.3.0 e V1 R1.4.0)!
Saluti,
Kimera.
-
Abbiamo la V1-R3.2.0, sapevo della 4 ma era ancora in FT fino a qualche giorno fa.
Giuseppe
-
Ah...già meglio.
Personalmente credo che serva una PSR (ammesso e non concesso che il resto sia fatto a modo e secondo indicazioni) da Siemens per attivare correttamente la sincronizzazione over wired ethernet (IEEE 1588) altrimenti non lo evidenzierebbero nelle R.N. come una cosa "da richiedere" a Siemens.
Edit: cito da documentazione di servizio...
Synchronization via LAN
In contrast to an air based synchronization mechanisms, synchronization via Ethernet (acc. IEEE1588, PTP Precious Time Protocol) requires less configuration. On the other hand, great demands are made on the Ethernet characteristics like symmetry, packet loss, delay, jitter (variance of delay). Therefore special requirements regarding the Ethernet components (especially the Ethernet switches used) have to be considered.
Exceeding of limits (especially of jitter) will lead to loss of synchronization, which will finally lead to a resynchronization process.
During this process the belonging base stations are unable to establish telephony connections.
The synchronization according Ethernet solely uses a star shaped topology. Maximally one base station serves a Synchronization Master, all other base stations which participate at the synchronization serve as Synchronization Slaves.
The main advantages of synchronization via LAN are:
- more flexibility in the location of the DECT IP base station - no need to built synchronization chains as with synchronization via DECT,
- less DECT IP base stations are required, because the overlapped area of DECT IP base station is less,
- configuration of DECT IP systems is simplified, because all DECT IP base stations can be synchronized to only one synchronization master.
A fronte di una semplicità di topologia di rete richiesta come pre-requisito offre una soluzione di facile implementazione...ma anche molto vulnerabile (fallace).
Saluti,
Davide.
-
ciao , mi intrometto perchè ho seguito la cosa con Giuseppe e ho eseguito test in laboratorio sempre su enterasis.
Come indicato nel manuale oltre che in una delle mie service info è obbligatorio l'uso delle vlan e non consigliato.
quindi fatto questo resta da capire perchè effettivamente passano messaggi diretti a 255.255.255.255
Personalmente credo servano per mantenere le celle sincronizzate e lavorando su una vlan diversa dalla vlan voce , il traffico non deve avere impatto sul resto della rete.
Le uniche porte tagged saranno le trunk oltre che la porta dove è collegata l'iwu che deve avere entrambe le vlanid sia quella dect che quella voce
tornando alla questione originale i test li ho fatti sulla v1r4.0 che implementa diverse novità oltre ai menu' interni per attivare direttamente sul dect le deviazioni , la seconda chiamata e un phonebook di gruppo che pero' resta vincolato alle abilitazioni e non segue il concetto dei numeri brevi.
Testato su osv, oso e h4k v5 e v6
Ci sono secondo me dei problemi e sono stato costretto a usare il sip on tcp in luogo del precedente udp .
questa opzione non è presente nella v1r3.2
Questo è uno dei motivi per cui non è ancora uscita, e poi sul 4000 non funzionano la seconda chiamata (nesun avviso) oltre ad altre cose.
su osv è pienamente funzionante ma c'è una anomalia sul pickup.
Ad ogni modo tornando al discorso di Giuseppe io credo che abbia ragione .
Ho già scritto a chi di dovere e conto di ricevere una risposta di cui vi informerò immediatamente.
-
ciao , entro fine mese esce la v1r4 e sarà modificata l'informazione sul 1588
-
Mitico Andrea, ma in che senso verrà modificata?
Significa che qualcosa che non andava c'era?
Ciao e buon We
Giuseppe
-
da quello che mi han detto il sincronismo avviene tramite il 1588 come ormai è noto ma non è esattamente lo standard del ptp ad essere usato.
quindi mi aspetto di leggere nella documentazione che i messaggi sono broadcast
nel dettaglio credo che questa riga del manuale debba essere corretta sostituendo la parola multicast con broadcast:
This PTP master
sends out multicast messages with time information
-
...ma in che senso verrà modificata?
Penso che Andrea Ripa intenda dire che con il rilascio GA di HiPath Cordless IP V1 R4 il requisito di una PSR (Project Specific Release) per il funzionamento con IEEE 1588 dovrebbe venire meno...
Saluti,
Kimera.
-
no, io intendo proprio che nella documentazione del dect ip è scritto che i messaggi di ptp sono multicast mentre la realtà è che sono broadcast.
-
Bump...ho inteso male Io...comunque mi pare che ci sia una certa confusione (forse in Siemens ?) perchè se nella Documentazione è espressamente citato lo standard IEEE 1588 (PTP) allora l'aderenza allo standard tale per cui: "All PTP messages are sent using multicast messaging. IEEE 1588-2008 introduces an option for devices to negotiate unicast transmission on a port-by-port basis." (tratto da qui (http://en.wikipedia.org/wiki/Precision_Time_Protocol)) comporta che, in presenza del famigerato Broadcast al posto del Multicast, (1) Siemens non sta implementando correttamente lo Standard di cui sopra (e non è che può usarne uno chiamandolo "IEEE 1588 secondo Siemens") oppure comporta che (2) stiamo basando la discussione su presupposti sbagliati (Broadcast)...quindi, secondo me, se c'è un errore non è nella documentazione che cita lo Standard ma nel modo in cui questo è evenutalmente messo in pratica.
Saluti,
Kimera.
-
ok ci sta e ti assicuro che non vedo l'ora di leggere i documenti della v1r4 , ad ogni modo attenzione perchè il 1588-2008 è il ptp v2
-
Anch'Io.
Sì ma dal punto di vista del traffico Multicast sia IEEE 1588-2002 (PTP) che IEEE 1588-2008 non differiscono come implementazione per quel che riguarda il "Message Transport" (Multicast).
Sarebbe interessante contattare qualcuno in Germania (Fastbyte potrebbe sottoporre la questione a qualche PL manager o qualche tecnico del prodotto).
Saluti,
Kimera.
-
ciao , entro fine mese esce la v1r4 e sarà modificata l'informazione sul 1588
Qualcuno ha news su questa versione?
Non l'ho ancora trovata sul SEBA
-
ciao è disponibile la v1r4.2
-
Riesumo un questo vecchio Thread per informarvi che HiPath Cordless IP V1 R5.0.0 è disponibile (Edit: come Field Trial) e che per scenari nei quali è necessario implementare il protocollo IEEE1588 (Sincronizzazione) via LAN e non via Aerea un preciso PSR va richiesto al relativo Product Manager: ulrich.mitreuter@unify.com
Saluti, Kimera.
-
Ciao, in cosa consiste ( in pratica non in teoria ) un PSR?
Grazie
Giuseppe
-
Ciao, sul sito Seba Unify mi da come ultima versione disponibile la V1R4.9.0
Giuseppe
-
Ciao, in cosa consiste ( in pratica non in teoria ) un PSR?
In pratica? Io direttamente non lo so...posso solo ipotizzare che sia (1) uno specifico rilascio software (ma ne dubito fortemente) che "sblocca" alcuni scenari non previsti oppure che (2) sia solo un modo per notificare Siemens/Unify di uno specifico scenario non sui-generis (ossia altamente specifico) che si vuole andare ad implementare...come nel caso di funzionalità implementate in modo non-standard (caso IEEE 1588 via LAN anzichè via Radio) o in uno scenario non-standard.
Tutto questo perchè mi è capitato di leggere questo trafiletto (è in Inglese ma è abbastanza indicativo) relativo ad un altro prodotto:
"With availability of the following listed releases:
the requirement of doing a project specific release (PSR) for installation of C with D and E applications operated on environment F is now obsolete.
Installations may be done without prior confirmation."
Ora...lascia stare cosa siano A, B, C, D, E ed F...la parola topica è "confirmation"...tradotto il tutto in italiano il significato è: con la disponibilità di A e/o B, la necessità di richiedere una PSR per l'installazione di C con le funzionalità D ed E operanti in un ambiente F è resa obsoleta...e l'installazione può avvenire senza CONFERMA.
Ora, per l'esattezza, in tedesco la frase finale originale che corrisponde a quella con la parola "confirmation" è "nun ohne vorherige Genehmigung" che significa "now without prior authorization" ovvero "adesso senza AUTORIZZAZIONE"...quindi il senso è che più di una conferma è una autorizzazione quella che Siemens/Unify va a rilasciare a seguito di una PSR...quindi, tra le altre cose, in Inglese avrebbero dovuto usare il termine "Approval" che è una traduzione ben più corretta.
Quanto esposto sopra mi fa propendere per (2): un'analisi sintattica...magari mi sbaglio ma penso che sia abbastanza indicativa la cosa.
Per "standard" Io intendo uno scenario (o delle funzionalità implementate in modo) certificato e/o supportato da Siemens/Unify.
Ovviamente penso che se una PSR va inviata a Siemens/Unify poi questi ultimi provvederanno a dare una risposta: tale risposta potrebbe contenere tanto delle indicazioni tecniche (se la fattibilità viene accertata) in modo che il tutto possa funzionare al meglio quanto la vera e propria fattibilità (sì possibile/no non possibile).
Tante belle parole eh...ma nulla di concreto...infatti piacerebbe anche a me capire quanti, in Italia, hanno inviato una PSR (che è una richiesta) a Siemens negli ultimi anni.
Ciao, sul sito Seba Unify mi da come ultima versione disponibile la V1 R4.9.0
Penso che la V1 R5.0.0 (tra fine Novembre e metà Dicembre 2013 era ancora in Field Trial) arriverà ufficialmente tra breve (Hai ragione...non è ancora ufficialmente disponibile).
New Features introdotte con HiPath Cordless IP V1 R5.0.0 (BSIP e Server):- Modified WBM with respect to new Media Gateway Deployment
- Option to change Location Area Level (LAL)
- DECT Roaming
- Support of SIP Roaming
-
Sembra che prima (o al posto) della versione HiPath Cordless IP V1 R5.0.0 Unify stia rilasciando, dopo la R4.9.0, la versione HiPath Cordless IP V1 R4.10.0 (Edit: al 11.02.2014 è rilasciata): quest'ultima non contiene le nuove funzionalità attribuite (almeno temporaneamente e per quello che si evince dalla documentazione) alla V1 R5.0.0 ma solo bugfixes.
Saluti, Kimera.