Magasabb szintű switch-elési technológiák L3, L4 switching, policy Erdős Balázs berdos@lanex.hu Thank you for attending this presentation to hear about the exciting new capabilities available with the newest version of CajunRules.

Tartalom Policy-based Networking előnyei és jövője Az Avaya Policy stratégiája CajunRulesä Policy Manager termékismertetés Load balancing Cajun P333R-LB bemutatása First, we will look at Avaya’s policy-based networking vision, benefits, and strategy in this new technology area. Then we’ll take a look at what Avaya has delivered with the CajunRules product. After that, we will wrap up and answer any questions you may have.

End-to-End QoS konvergáló környezetben DEFINITY® ECS Gatekeeper/ Gateway LAN Switched Ethernet & Routing Corporate IP WAN LAN VPN/ Firewall/ Router Switched Ethernet & Routing VPN/ Firewall/ Router IP Ethernet or Soft phones Analog, Digital Wireless phones INTUITYä AUDIX CajunRules QoS Policy Manager

A policy-alapú networking előnyei Hálózati policy-k és jellemzők: Védi a kulcsfontosságú alkalmazásokat Beállítja a csoport- és eszközpolicy-t, akár egyidejűleg többet is Inhomogén hálózatban optimalizálja a sávszélességet– Avaya Cajun® Portfolio és 3rd-party devices Minden hálózati forgalomra rákényszeríti a policy-t – adat, VoIP, média stream, … Avaya is driving simplification into every aspect of the network management experience so network managers can spend more time on the needs of the business and less time being mired in the details of each particular product. The fundamental goal of CajunRules is to find the most effective way of supporting mission-critical services that have differentiated service requirements. Because of the importance of the networked economy and e-business to our customers, it is critical for Avaya to link policy-based networking with its products and to our partner‘s products to deliver compelling, productive solutions in this area. Avaya is also pursuing the goal of interoperating with a variety of different applications and end points (devices), from Avaya products such as soft phones and messaging gateways to partner companies' end points and applications such as Microsoft, Sun, Netscape, and HP. This is a compelling roadmap to be pursuing and an incredibly motivating and valuable line of activity in our product efforts.

Az Avaya Policy stratégiája Üzleti célok határozzák meg a hálózat működését. A hálózat működését inkább a felhasználók és az alkalmazások igényei határozzák meg, mintsem az eszközök. CajunRules Policy Manager integrált policy management-et nyújt a konvergáló hálózatok számára. Központilag policy-kat definiál magas szintű belső szabályok alapján. A policy-szabályok működési paramétereket határoznak meg, és az egész hálózatban érvényre jutnak. Business Applications User Community Payroll Deny Access Accounting Orders/Inventory High Priority Engineering Best Effort Email Services This is an example of how a policy-based management works. On the left are the defined user communities and on the right are the applications that sit on the network. At the center is the network with policies enabled on the infrastructure equipment/devices. Someone in the Telemarketing group has tried to access the Payroll information. A policy was not defined to enable access for this user group and it was subsequently denied. Telemarketing does have high priority access to the Orders and Inventory application. The Accounting group has high priority access to both the Payroll and Orders/Inventory applications. For all user groups, e-mail has been defined as a low priority application. Marketing Telemarketing

CajunRules termékismertetés Architektúra Web-based GUI Policy Engine LDAP & EDG LDAP Directory Translation Services Policy tartományba szervezett eszközök Event System Device Object Model Policy Server LDAP SNMP Starting on the left and from a functional perspective the Web-based GUI communicates with the policy server application via a Java RMI interface. RMI is the remote method invocation interface associated with Java and allows the client to be local or remote from the server, at the user’s choice, The policy server is made up of a couple of different entities: the policy engine (PE), the device object model (DOM), an event subsystem, and the proxy translation engine (PTE). These entities work in conjunction to provide the robust policy server. The PE is responsible for receiving all of the graphical user interface actions created as rules are defined. The DOM is responsible for communication to SNMP devices as well as the modeling of the different objects associated with the network including users and the applications. The PE takes the information that has been modeled as well as the rules created and utilizes LDAP to store that information in a directory-Novell’s NDS, Netscape's Directory Server, or Microsoft's Active Directory. The PE communicates with QIP and accesses its database of users and IP addresses, and IP network infrastructure information. The event subsystem monitors all of the other systems for particular events -- policy changes such as an update to a specific domain, and overall health of the system and the policy services. CajunRules provides the concept of multiple policy domains enabling different types of policies to be assigned to each. This allows varied business requirements, specific areas or specific campuses within the environment to be addressed individually. Multiple domains can be created and policies can be applied to addressed each individual domain. To summarize, the Web-based GUI represents a graphical user interface to create a policy. Easily-definable device object models take care of all the complex translations and store that in a directory in CIM format. Once that's all been done policy is applied to the network. The PE sends out an SNMP trigger to the devices in the network that are LDAP-enabled telling them that their policy has been updated. The devices in turn will go to their local directory server to pull down their new policy information. For those devices that are not LDAP-enabled, the PTE translates the schema that stored into the directory and places it in a configuration file devices understand. Telnet is used to access the devices and the new configuration is downloaded. Telnet/CLI OSSI Definity® Server

CajunRules termékismertetés End-to-End QoS támogatás gyártófüggetlen módon Minden stratégiai Avaya eszközre: P120, P130, P330, P550, P580, P880, & P882 Az Avaya ECLIPS rendszerére (running 9.5) VoIP számára Marconi switch-ek: ES5000 & ES6000 Cisco (IOS 11.2 +): 2500, 7200, & 7500 Flexibilis Directory Service és OS támogatás Novell NDS (8.5) és Netscape Directory (4.12) Platform: Windows NT/2000 és Sun Solaris Integráció a CajunView® Network Manager-el Version 2.1 adds support for P130 Cajun switches to compliment the P330, P550, and P880. Support for Cisco 7200s is also added to make CajunRules a better choice for mixed Cajun switch and Cisco router environments. Now your customers can use the directory they have standardized on or the one they are most familiar - Microsoft Active Directory is now supported adding to the existing support for NetScape and Novel NDS eDirectory. Additionally, integration with CajunView significantly reduces initial setup for CajunRules. With the ability to import discovered device information, both the requirement for manual entry of data and the potential for errors is greatly reduced.

Voice Over IP Policy-k A CajunRules támogatja az Enterprise Class IP-t a VoIP QoS Policy beállításához Szinkronizálja a VoIP QoS-t az ECLIPS termékek és hálózati eszközök között Enterprise Directory Gateway-t használ a VoIP csomagok jelölésére IP végpontokhoz is eljut a Policy Megengedi a switch-eknek/router-eknek a VoIP csomagazonosítást és a QoS priority hozzáadását Diff-Serv, 802.1p, UDP port tartomány CajunRules 2.1establishes priorities for network devices that receive their prioritization from CR based upon DiffServ Code Points defined and written into the Enterprise Directory Gateway (EDG). CR will provide support for the management of the QoS parameters introduced in DEFINITY Release 9. CR communicates these QoS policy-based rules to DEFINITY via the EDG. EDG contains LDAP schema for DEFINITY administration data and communicates with DEFINITY via the proprietary OSSI protocol. The LDAP schema in the EDG will be extended to include the QoS parameters described above. CR populates the DEFINITY-specific QoS LDAP schema in the EDG. The EDG will then send the updated QoS parameters to DEFINITY via the OSSI protocol. CR will also communicate these same QoS policy rules to the various data switches and routers in the network, so there is consistent quality of service across the network for the voice packets. 23

CajunRules termékismertetés DEFINITY® IP Server támogatás Let’s take a more detailed look at how this works. EDG contains an LDAP schema for DEFINITY administration data and communicates with DEFINITY over the proprietary OSSI protocol. The LDAP schema in the Enterprise Directory Gateway will be extended to include QoS parameters. CR will populate the DEFINITY-specific QoS LDAP schema in the Enterprise Directory Gateway. The Enterprise Directory Gateway will then send the updated QoS parameters to DEFINITY via the OSSI protocol. CR will also communicate these same QoS policy rules to the various data switches and routers in the network, so that there can be consistent quality of service across the network for the voice packets.

CajunRules Policy Manager termékismertetés Érvényesítés/jóváhagyás Ha az illető eszközre vonatkozó szabály érvénytelen, nem is érvényesül, nehogy a hálózat működését veszélyeztesse. A szabályok részleges érvényesülését támogatja. Időzónák A CajunRules Policy Manager belső intelligenciája az időzónának megfelelő policy-t alkalmazza. Pl. a 9-to-5 az 9-to-5-öt jelent függetlenül az időzónától és a földrajzi elhelyezkedéstől. CR will validate the policy defined for each target in the domain. The validation may either be done by CR itself, based on knowledge of device/version/interface capabilities and properties, or it may be out-sourced to the device itself, such as the P330. Validation is performed automatically when a policy is associated with a domain, before a policy change is enforced, and whenever a device is added to a domain (as domains always have an enforced policy). Validation can also be requested explicitly by the user. The user will receive feedback about validity and enforceability of the policy at the time the policy is defined. In order to validate the policy, CR has to validate all combinations of rules (and services) that would be activated together at different times. In the event a device exists that is different from other devices, meaning certain rules or policies would not pertain, a partial enforcement of the policy is possible. This means the policy will be enforced on all devices that support the policy or feature and will not be enforced on those that don’t. Policy domains have a time zone attribute. By default, it is the same time zone as the “Absolute Time” (CR Server host’s time zone). Each activation period in a rule will have a time zone attribute that defines whether it is domain-local-time or “Absolute Time”. Both time zone attributes of the policy domain and the activation period are viewable and user settable (via GUI).

CajunRules Policy Manager termékismertetés sávszélesség policy és queuing Sávszélesség policy bevezetése Avaya, Marconi switch-ekre és Cisco IOS 11.2+ -ra A sávszélesség felhasználó által beállítható szolgáltatás Queuing IP Precedence 0-7-et használ Szinkronizál különböző queuing technikák között (Class-Based and custom queuing) Bandwidth policy creation is extremely flexible as they can be created generically (as an abstract policy) and then customized for a specific application or user or device. IP Precedence is used to explicitly classify traffic by certain precedence values. This field can be expressed in terms of 8 IP-Precedence values (0-7). This rule condition is made of this field AND the other fields such as source and destination. IP Precedence is similar to 802.1p but it takes place at layer 3. CajunRules provides synchronization of different queuing techniques for the different devices (Cajun uses priority queuing, while Cisco uses class-based queuing). The focus of this capability is to ensure consistent behavior for handling traffic irrespective of the device or manufacturer.

CajunRules Policy Manager termékismertetés Szolgáltatás definiálás A szolgáltatás neve meghatározza a szabályok szerinti prioritást. A szolgáltatások további, berendezésfüggő paramétert definiálnak A szolgáltatás definiálás cél-specifikus – per eszköz/interface/csoport Egyedi szolgáltatás megoldás CAR, Custom Queuing, CBQ, stb. számára A szokások a szerviz definícióban vannak meghatározva a szolgáltatás szabályainak megfelelően. Services may be defined explicitly for each enforcement target based on the capabilities of the target. These capabilities include, but are not limited to, priority level, coloring, bandwidth allocation, conformance limiting, shaping, and queueing. Referencing a service in an abstract rule implicitly defines what priority the traffic should receive. When multiple rules reference the same service, the behavior specified in the service definition is applied to each of the rules separately rather than to the ‘aggregate’ of all rules. Referencing the same service means these rules will get parallel treatment, it does not mean they are related. CR has the following pre-defined services: ‘Service-0’, implying lowest forwarding priority and 802.1p value of 0, (equivalent to the RNR1.0 action of ‘Fwd/Priority 1 (Low)’), ‘Service-1’ … ‘Service-7’, implying highest forwarding priority and 802.1p value of 7, (equivalent to the RNR1.0 action of ‘Fwd/Priority 8 (High)’), ‘Deny’, meaning drop the packets. ‘Permit’, meaning forward as is, without modification and with no special service (i.e. best effort forwarding). Service-names in the abstract policy are limited to the pre-defined ones. Each of the pre-defined services implies some behavior definition on each target. By default, the traffic of each rule that references this service will get this behavior on the enforcement target. Where applicable, these default service definitions can be modified by the user for given targets.

CajunRules Policy Manager termékismertetés 2 CajunRules Policy Manager termékismertetés 2.1 Abstract and Custom Policy Editor Abstract Policy Az egész tartományra vonatkozik Elrejti a berendezések közötti különbségeket Automatikus fordítás Policy testre szabás Cél meghatározás - per eszköz/interface/csoport Igény esetén finomhangolható queuing technikák szinkronizálása Translation-view eszközspecifikus policy A policy is a set of rules. They are application and user-group oriented. Each rule specifies certain traffic by means of source and destination network entities and/or applications, an indication of bi-directional/uni-direction traffic, an activation period, and an action indicating the treatment the traffic should receive. The rules of the abstract policy are general and not specific to certain devices/interfaces. A policy associated with a domain applies to all the devices in the domain. After the abstract policy is created, customization can be done for specific enforcement targets. An abstract rule can be either bi-directional or unidirectional. Each rule specifies a service-name that identifies a service. The service defines the behavior that devices should give to the traffic specified by this rule. Where applicable, service definitions can be modified by the user for given targets. Rules can be customized for specific enforcement targets. A target can be a device, a router interface, or groups of either. A policy can be viewed and edited for a given target. The target-specific view is called the Custom Policy for that target. CR may have, for each policy, a tree of target-specific Custom Policies related to the abstract policy. The Custom Policy, like the abstract policy, is made of a list of rules, but with more target-specific details. The level of detail here introduces the following: Breakup of bi-directional rules into their unidirectional components Ability to specify Mandatory enforcement of individual rules (directions) Ability to disable translation for individual rule (directions) Ability to specify a different service class for individual rule (directions) The Translation View is specific to a certain policy on a certain device/interface at a certain time. CR will show as much detail as available with regard to the instructions being sent to the given device(s). For example, the ACL numbers that would be used by CR on a Cisco device depend on wider context, such as the policy of another domain that has interfaces on that router. The TranslationView presents rules as unidirectional, with explicit classification criteria - IP addresses, masks, port numbers. It translates abstract application definitions to TCP/UDP ports and/or IP addresses.

CajunRules Policy Manager termékismertetés példa: Cisco eszköz IOS 11.2 és a fölötti támogatás Telnet/CLI-n keresztüli átkonfigurálhatóság end-to-end QoS CR 2.1 supports Cisco 7500, 7200, and 2500 routers running IOS version 11.2 or later. CR can configure QoS policies and filtering (access control) policies on Cisco devices. QoS policies include priority queuing, coloring (setting IP precedence), bandwidth limiting, bandwidth allocation (Custom Queues), and shaping. CR translates the policy into Cisco CLI commands. Filtering rules are enforced by access-lists. QoS policy rules are translated using different Cisco CLI commands, including route-maps, rate-limit (CAR), different queuing commands, and more. CR pushes the translated policy to the device via Telnet. CR uses SNMP to read information from the router. RNR presents router interfaces to the user and lets the user assign interfaces to policy domains.

CajunRules Policy Manager termék jövője Integráció a DEFINITY Communications Server for VoIP QoS Policy termékkel CajunRules Policy Manager segít szinkronizálni a VoIP-t QoS-t a DEFINITY és a switch-ek/router-ek között CajunRules Policy Manager megmondja a Definity Communications Server-nek, hogyan jelölje a VoIP csomagokat CajunRules Policy Manager megmondja a switch-eknek/router-eknek hogyan kell azonosítani és kezelni a VoIP csomagokat Diff-Serv, 802.1p, UDP Enterprise Directory Gateway integráció In the future, CajunRules will establishe priorities for network devices that receive their prioritization from CR based upon DiffServ Code Points defined and written into the Enterprise Directory Gateway (EDG). CR will provide support for the management of the QoS parameters introduced in DEFINITY Release 9. CR communicates these QoS policy-based rules to DEFINITY via the EDG. EDG contains LDAP schema for DEFINITY administration data and communicates with DEFINITY via the proprietary OSSI protocol. The LDAP schema in the EDG will be extended to include the QoS parameters described above. CR populates the DEFINITY-specific QoS LDAP schema in the EDG. The EDG will then send the updated QoS parameters to DEFINITY via the OSSI protocol. CR will also communicate these same QoS policy rules to the various data switches and routers in the network, so there is consistent quality of service across the network for the voice packets. 23

Mi is a Load Balancing? Load Balancing erőforrások közötti terhelés megosztására szolgál. Magas rendelkezésre állás: ha bármelyik hálózati eszközöm kiesik, akkor a másik transzparens módon a helyébe lép. Áteresztőképesség: csökkenti ez egyes eszközökön keresztüli forgalmat (pl.: tűzfalak). Transzparens: mindezek a hálózat átkonfigurálása nélkül teljesíthetők. Load Balancing szünetmentes hálózati működés!

Az Avaya P333R-LB A P333R-LB Load Balancing tornyozható switch P333R-LB Layer 4 Load-Balancing-ot és Routing nyújt 24*10/100 ports + expansion slot + Stacking slot

Server Load Balancing A külvilág számára egyetlen „virtuális szerver” látható P333R-LB fogadja a bejövő kezdeményezéseket és a kommunikációt ketté bontja Virtual Server Real Servers Internet

Server Load Balancing Server Load Balancing az összes TCP/UDP-t használó applikáció számára pl.: HTTP, FTP, DNS Rugalmas Független a hálózat fizikai topológiájától Load Balancing típusok Round Robin Hash A fentiek variációja Válaszidő alapú *future

Server Load Balancing Magas rendelkezésre állás Server Health Check típusok: Ping-alapú TCP connection HTTP szint Server backup Real Server Group Real Server *future

Server Load Balancing példa

Firewall Load Balancing Több tűzfal párhuzamos működését teszi lehetővé: Skálázható tűzfal performancia Redundáns működés LAN Firewall Farm Internet

Firewall Load Balancing Rugalmas Firewall Load Balancing: Transparens routing tűzfalak számára (nincs NAT) Nem transzparens routing tűzfalak számára (van NAT) Bridging tűzfalak számára Firewall Load Balancing skálázhatóság: Hash Weighted hash Elérhetőség: Firewall health checks típusok: Ping alapú TCP connection HTTP szint *future

Firewall Load Balancing példa

Application és Cache Redirection Rugalmas aplikáció átirányítás Transparent cache (HTTP redirection) Tartalom vizsgálat (non-HTTP) LAN LAN Internet

Application és Cache Redirection Maximális elérhetőség: Cache Health Checks típusok Ping alapú TCP connection HTTP szint Ha a cash nem elérhető, akkor a szerver felé fordul További optimalizálási lehetőségek Cache kikerülés, nem cash-elhető site-ok esetén Különböző cache farmok konfigurálása különböző helyszínek esetén *future

Application (Cache) Redirection

P333R-LB Policy based Load Balancing Különböző felhasználók különböző szervereket érnek el A szervereken ugyanaz az alkalmazás fut Mindenki ugyanazt a „virtuális IP címet”(VIP) látja Az erőforrások más csoportok számára is „kölcsönbe adhatók” a folyamatos szolgáltatás biztosítása végett “Gold” Servers Avaya P333R-LB Internet “Silver” Servers “Bronze” Servers *future

Köszönöm a figyelmet!