E’ notizia di ieri, 25 Novembre, che il Ripe (registro Internet regionale per l’Europa, l’Asia occidentale e l’ex Unione Sovietica) ha allocato l’ultima /22 di indirizzi IPv4.
Gli addetti del settore non si sorprenderanno in quando erano anni che si anticipava questa situazione.
Nel 2012, il Ripe aveva infatto comunicato che la loro unica rimasta /8 di indirizzi IPv4 sarebbe stata l’ultima fonte di /22 per i nuovi LIR.
Questo inevitabilmente darà una scossa a quei Service Provider, Hosting Provider, network engineers che hanno sempre posticipato l’adozione dell’indirizzamento IPv6.
Nel 2020 continueremo ad erogare con più forza e più frequentemente il corso MTCIPv6E per aiutare, formare e supportare i professionisti e le aziende in questa nuova sfida.
Di seguito la notizia dal sito ufficiale del Ripe:
Grazie alla presenza nel nostro team di un Trainer MikroTik Certificato siamo in grado di organizzare corsi di formazione e di rilasciare attestati MikroTik RouterOs relativi alle 8 certificazioni (I, II e III livello).
Analisi, ottimizzazione e potenziamento infrastrutture di rete
Grazie ad un’esperienza decennale nel settore delle telecomunicazioni centrato sul Networking, offriamo supporto e progettazione per ottimizzare e potenziare ogni tipo di infrastruttura di Rete. E’ possibile richiedere una consulenza per analizzare la situazione di Rete attuale e valutare la soluzione migliore per soddisfare in toto le esigenze aziendali. Il primo step consisterà in un’analisi approfondita dell’infrastruttura e nell’individuazione dei processi che creano malfunzionamenti, rallentamenti ed inefficienze. Verrà poi redatto un report dettagliato e verranno vagliate le possibili soluzioni da intraprendere per ottimizzare il business.
Implementazione di un’infrastruttura con protocolli di routing dinamico
Servizio dedicato ad aziende che già possiedono una propria infrastruttura ma che hanno l’esigenza di renderla maggiormente performante e affidabile tramite l’introduzione di Protocolli di Routing Dinamico: garantiscono un’elevata funzionalità e diminuiscono le operazioni occorrenti per implementare una modifica all’infrastruttura di Rete (ad es. aggiungere ponti radio o nuovi utenti). A fronte di un’accurata analisi dell’attuale situazione della Rete si implementeranno i Protocolli necessari per creare una Rete Layer 3 con l’aggiunta della tecnologia MPLS per sostenere prestazioni più elevate.
Gestione rapporti e pratiche RIPE
RIPE è uno dei cinque Regional Internet Registry (RIR) esistenti in ambito IANA con delega per l’assegnazione degli indirizzamenti IPv4 e IPv6 in Europa, Medio Oriente e Asia Centrale. Per ottenere IPv4, IPv6 e numero di AS è necessario diventare membro del RIPE: offriamo consulenza per la parte burocratica di affiliazione, assegnazione degli indirizzamenti e per la fase tecnica di messa in produzione.
Commenti disabilitati su BGP (Border Gateway Protocol) su MikroTik
Il protocollo BGP, Border Gateway Protocol è un protocollo di routing dinamico usato perconnettere tra loro più router che appartengono a “sistemi autonomi” (AS) diversi. È quindi un protocollo di routing inter-AS, classificato come protocollo di “Exterior Gateway”, ovvero utilizzato per inviare le proprie route a organizzazioni esterne (e per ricevere le route di organizzazioni esterne).
Il BGP è il protocollo di routing per antonomasia, sul quale è basato il funzionamento di internet.
Di seguito un esempio base di configurazione del BGP su RouterOS tramite CLI, è possibile configurare tutto anche tramite Winbox/Webfig.
Ipotizziamo che il nostro numero di AS sia AS12345, l’indirizzo ip è 172.16.255.1, our public IP range received by RIPE or other similar organization is 201.201.240.0/21. L’ AS number del nostro peering ISP1 is AS11111, il suo indirizzo di peering è 172.16.255.2. Non useremo una password MD5 in questo esempio.
Di seguito l’immagine con lo schema dell’esempio :
Configurazione del progcesso globale del BGP /routing bgp instance set default as=12345 redistribute-static=no redistribute-connected=no /routing bgp network add network=201.201.240.0/21 synchronize=no
Filters BGP-out – permetteremo solo l’annuncio delle nostre reti. Se il processo BGP proverà ad annunciare altre rotte, queste saranno bloccate dal filtro.
Nel nostro esempio, ISP1 è un link di backup per cui dovremo creare una regola particolare nella chain di filter-out. Per ottenere questo risultato faremo si che la path verso ISP1 sia più lunga che quella tramite ISP2.
Come risultato finale tutto il traffico in ingrasso arriverà tramite ISP2 mentre ISP1 rimarrà come backup nel caso che ISP2 abbia problemi.
Filters BGP-in – Non vogliamo ricevere da altri peer reti “dannose”, come reti private o bogons e tanto meno le nostre networks.
Used to distinguish new sessions and visits. This cookie is set when the GA.js javascript library is loaded and there is no existing __utmb cookie. The cookie is updated every time data is sent to the Google Analytics server.
30 minutes after last activity
__utmc
Used only with old Urchin versions of Google Analytics and not with GA.js. Was used to distinguish between new sessions and visits at the end of a session.
End of session (browser)
__utmz
Contains information about the traffic source or campaign that directed user to the website. The cookie is set when the GA.js javascript is loaded and updated when data is sent to the Google Anaytics server
6 months after last activity
__utmv
Contains custom information set by the web developer via the _setCustomVar method in Google Analytics. This cookie is updated every time new data is sent to the Google Analytics server.
2 years after last activity
__utmx
Used to determine whether a user is included in an A / B or Multivariate test.
18 months
_ga
ID used to identify users
2 years
_gali
Used by Google Analytics to determine which links on a page are being clicked
30 seconds
_ga_
ID used to identify users
2 years
_gid
ID used to identify users for 24 hours after last activity
24 hours
_gat
Used to monitor number of Google Analytics server requests when using Google Tag Manager
1 minute
_gac_
Contains information related to marketing campaigns of the user. These are shared with Google AdWords / Google Ads when the Google Ads and Google Analytics accounts are linked together.
90 days
__utma
ID used to identify users and sessions
2 years after last activity
__utmt
Used to monitor number of Google Analytics server requests