Maintenance Release 6.6.5.77.R02 voor OmniSwitch 6250-6450 gepubliceerd

tech-update

Er is nu een nieuwe Maintenance Release gepubliceerd voor de Alcatel-Lucent OmniSwitch 6250 en 6450. Deze release bevat, naast de gebruikelijke bugfixes de volgende nieuwe functionaliteit:

1. DHCP Snooping Global Mode Enhancement

Om flexibiliteit en meer veiligheidsmechanismen te bieden voor Enterprise klanten om DHCP snooping in hun omgeving te implementeren zijn er een aantal opties toegevoegd. Met DHCP snooping wordt een vertrouwde of onvertrouwde status toegekend aan een switchpoort. Hierdoor wordt het mogelijk om alleen door voor de organisatie bekende DHCP-servers op vertrouwde switchpoorten ip-adressen uit te geven. Een illegale DHCP-server, die op een willekeurige host achter een onvertrouwde switchpoort is aangesloten, kan geen adres meer toekennen. DHCP-snooping valideert ieder DHCP-netwerkpakket dat van een DHCP-server op een onvertrouwde interface binnenkomt.

Door opties toe te voegen aan de maintenance release kan het AOS apparaat voorspelbaar werken. Dit stelt de gebruiker in staat configureerbare vlaggen te kiezen wat resulteert in het verwachte gedrag dat hieronder staat beschreven:

udpGblSbUturn Modus 6.6.5.R02
0 Standaard oude gedrag als in GA Release
1 Als deze variabele geselecteerd is zullen unicast BOOTP geen DHCP snooping functionaliteit volgen en zal er geen binding tabel hiermee opgebouwd worden
2 Hardware modus Nieuwe hardware instellingen waarbij alleen de combinatie van UDP poorten 68/67 als bron- en doel poort als DHCP pakketten behandeld zullen worden.Bv. als er een pakket met als bron UDP poort 67 en als doel UDP poort 67 wordt ontvangen, dan zal dit niet als DHCP gezien worden en niet door DHCP snooping onderschept worden.
3 Software modus Nieuwe hardware instellingen om pakketten met UDP poort paar 67/67 naar de CPU te onderscheppen, naast UDP poort paren 67/68 en 68/67.Nieuwe software forwading logica in DHCP snooping context verbeterd om L2, L3 switching (ARP) en L3 routing (IP Route) af te handelen

2. Critical Voice Vlan – fase 1

Het bestaande gedrag is dat, wanneer de RADIUS server niet meer reageert of toegankelijk is, een authentiserende IP telefoon naar het standaard VLAN verplaatst wordt, wat niet noodzakelijkerwijs het Voice VLAN is. Dit kan er toe leiden dat IP telefoons niet kunnen verbinden. Als een verbetering wordt de huidige auth-server down functie gebruikt om het critical voice VLAN te ondersteunen. Er wordt een nieuwe policy geïntroduceerd om één “Voice” User Network-Profile te ondersteunen.

Met deze uitbreiding wordt het MAC adres van het apparaat tegen de LLDP database gecontroleerd, als RADIUS authenticatie mislukt omdat de server niet reageert. Als bepaald wordt dat het een telefoon betreft, wordt het MAC adres geleerd en geclassificeerd in het “Voice-user-network-profile”. Als zo’n voice profiel niet aangemaakt is, dan wordt het apparaat als, hieronder beschreven, niet-IP apparaat geclassificeerd.

Als het MAC adres niet van een IP telefoon is wordt de normale policy toegepast. Bij de normale policy wordt, als UNP is geconfigureerd, een MAC adres geleerd en geclassificeerd in het betreffende profiel. Als er geen User-Network Profile is geconfigureerd, wordt het MAC adres geblokkeerd en als gefilterd geleerd.

Voor meer informatie kunt u de release note bekijken en de firmware downloaden op onze support pagina →