 vssnsarma
Rating: 76
Member since: 2008-09-08
Feeds: 2
Bookmarks
|
Preview: Master in Networking
Master in NetworkingUpdated: 2010-01-14T07:12:10.723-08:00
SNMP Interoperability 2008-12-23T06:25:53.975-08:00 As presently specified, SNMPv2 is incompatible with SNMPv1 in two key areas: message formats and protocol operations. SNMPv2 messages use different header and protocol data unit (PDU) formats than SNMPv1 messages. SNMPv2 also uses two protocol operations that are not specified in SNMPv1. Furthermore, RFC 1908 defines two possible SNMPv1/v2 coexistence strategies: proxy agents and bilingual network-management systems. SNMP Proxy Agents An SNMPv2 agent can act as a proxy agent on behalf of SNMPv1 managed devices, as follows:
The proxy agent maps SNMPv1 trap messages to SNMPv2 trap messages and then forwards them to the NMS. Bilingual SNMPv2 network-management systems support both SNMPv1 and SNMPv2. To support this dual-management environment, a management application in the bilingual NMS must contact an agent. The NMS then examines information stored in a local database to determine whether the agent supports SNMPv1 or SNMPv2. Based on the information in the database, the NMS communicates with the agent using the appropriate version of SNMP. 
SNMP Security 2008-12-23T06:19:57.560-08:00 SNMP lacks any authentication capabilities, which results in vulnerability to a variety of security threats. These include masquerading occurrences, modification of information, message sequence and timing modifications, and disclosure. Masquerading consists of an unauthorized entity attempting to perform management operations by assuming the identity of an authorized management entity. Modification of information involves an unauthorized entity attempting to alter a message generated by an authorized entity so that the message results in unauthorized accounting management or configuration management operations. Message sequence and timing modifications occur when an unauthorized entity reorders, delays, or copies and later replays a message generated by an authorized entity. Disclosure results when an unauthorized entity extracts values stored in managed objects, or learns of notifiable events by monitoring exchanges between managers and agents. Because SNMP does not implement authentication, many vendors do not implement Set operations, thereby reducing SNMP to a monitoring facility. 
SNMP Management 2008-12-23T06:19:07.068-08:00 SNMP is a distributed-management protocol. A system can operate exclusively as either an NMS or an agent, or it can perform the functions of both. When a system operates as both an NMS and an agent, another NMS might require that the system query manage devices and provide a summary of the information learned, or that it report locally stored management information. 
SNMP Version 2 2008-12-23T06:18:02.689-08:00 SNMP version 2 (SNMPv2) is an evolution of the initial version, SNMPv1. Originally, SNMPv2 was published as a set of proposed Internet standards in 1993; currently, it is a draft standard. As with SNMPv1, SNMPv2 functions within the specifications of the Structure of Management Information (SMI). In theory, SNMPv2 offers a number of improvements to SNMPv1, including additional protocol operations. SNMPv2 and Structure of Management Information The Structure of Management Information (SMI) defines the rules for describing management information, using ASN.1. The SNMPv2 SMI is described in RFC 1902. It makes certain additions and enhancements to the SNMPv1 SMI-specific data types, such as including bit strings, network addresses, and counters. Bit strings are defined only in SNMPv2 and comprise zero or more named bits that specify a value. Network addresses represent an address from a particular protocol family. SNMPv1 supports only 32-bit IP addresses, but SNMPv2 can support other types of addresses as well. Counters are non-negative integers that increase until they reach a maximum value and then return to zero. In SNMPv1, a 32-bit counter size is specified. In SNMPv2, 32-bit and 64-bit counters are defined. SMI Information Modules The SNMPv2 SMI also specifies information modules, which specify a group of related definitions. Three types of SMI information modules exist: MIB modules, compliance statements, and capability statements. MIB modules contain definitions of interrelated managed objects. Compliance statements provide a systematic way to describe a group of managed objects that must be implemented for conformance to a standard. Capability statements are used to indicate the precise level of support that an agent claims with respect to a MIB group. An NMS can adjust its behavior toward agents according to the capabilities statements associated with each agent. SNMPv2 Protocol Operations The Get, GetNext, and Set operations used in SNMPv1 are exactly the same as those used in SNMPv2. However, SNMPv2 adds and enhances some protocol operations. The SNMPv2 Trap operation, for example, serves the same function as that used in SNMPv1, but it uses a different message format and is designed to replace the SNMPv1 Trap. SNMPv2 also defines two new protocol operations: GetBulk and Inform. The GetBulk operation is used by the NMS to efficiently retrieve large blocks of data, such as multiple rows in a table. GetBulk fills a response message with as much of the requested data as will fit. The Inform operation allows one NMS to send trap information to another NMS and to then receive a response. In SNMPv2, if the agent responding to GetBulk operations cannot provide values for all the variables in a list, it provides partial results. 
SNMP Version 1 2008-12-23T06:15:47.029-08:00 SNMP version 1 (SNMPv1) is the initial implementation of the SNMP protocol. It is described in Request For Comments (RFC) 1157 and functions within the specifications of the Structure of Management Information (SMI). SNMPv1 operates over protocols such as User Datagram Protocol (UDP), Internet Protocol (IP), OSI Connectionless Network Service (CLNS), AppleTalk Datagram-Delivery Protocol (DDP), and Novell Internet Packet Exchange (IPX). SNMPv1 is widely used and is the de facto network-management protocol in the Internet community.SNMPv1 and Structure of Management Information The Structure of Management Information (SMI) defines the rules for describing management information, using Abstract Syntax Notation One (ASN.1). The SNMPv1 SMI is defined in RFC 1155. The SMI makes three key specifications: ASN.1 data types, SMI-specific data types, and SNMP MIB tables.SNMPv1 and ASN.1 Data TypesThe SNMPv1 SMI specifies that all managed objects have a certain subset of Abstract Syntax Notation One (ASN.1) data types associated with them. Three ASN.1 data types are required: name, syntax, and encoding. The name serves as the object identifier (object ID). The syntax defines the data type of the object (for example, integer or string). The SMI uses a subset of the ASN.1 syntax definitions. The encoding data describes how information associated with a managed object is formatted as a series of data items for transmission over the network.SNMPv1 and SMI-Specific Data TypesThe SNMPv1 SMI specifies the use of a number of SMI-specific data types, which are divided into two categories: simple data types and application-wide data types.Three simple data types are defined in the SNMPv1 SMI, all of which are unique values: integers, octet strings, and object IDs. The integer data type is a signed integer in the range of –2,147,483,648 to 2,147,483,647. Octet strings are ordered sequences of 0 to 65,535 octets. Object IDs come from the set of all object identifiers allocated according to the rules specified in ASN.1.Seven application-wide data types exist in the SNMPv1 SMI: network addresses, counters, gauges, time ticks, opaques, integers, and unsigned integers. Network addresses represent an address from a particular protocol family. SNMPv1 supports only 32-bit IP addresses. Counters are non-negative integers that increase until they reach a maximum value and then return to zero. In SNMPv1, a 32-bit counter size is specified. Gauges are non-negative integers that can increase or decrease but that retain the maximum value reached. A time tick represents a hundredth of a second since some event. An opaque represents an arbitrary encoding that is used to pass arbitrary information strings that do not conform to the strict data typing used by the SMI. An integer represents signed integer-valued information. This data type edefines the integer data type, which has arbitrary precision in ASN.1 but bounded precision in the SMI. An unsigned integer represents unsigned integer-valued information and is useful when values are always non-negative. This data type redefines the integer data type, which has arbitrary precision in ASN.1 but bounded precision in the SMI.SNMP MIB TablesThe SNMPv1 SMI defines highly structured tables that are used to group the instances of a tabular object (that is, an object that contains multiple variables). Tables are composed of zero or more rows, which are indexed in a way that allows SNMP to retrieve or alter an entire row with a single Get, GetNext, or Set command.SNMPv1 Protocol OperationsSNMP is a simple request/response protocol. The network-management system issues a request, and managed devices return responses. This behavior is implemented by using one of four protocol operations: Get, GetNext, Set, and Trap. The Get operation is used by the NMS to retrieve the value of one or more object instances from an agent. If the agent responding to the Get operation cannot provide values for all the object inst[...]
SNMP and Data Representation 2008-12-23T06:12:50.476-08:00 SNMP must account for and adjust to incompatibilities between managed devices. Different computers use different data representation techniques, which can compromise the capability of SNMP to exchange information between managed devices. SNMP uses a subset of Abstract Syntax Notation One (ASN.1) to accommodate communication between diverse systems. 
SNMP Management Information Base 2008-12-23T06:11:39.809-08:00 SNMP Management Information Base A Management Information Base (MIB) is a collection of information that is organized hierarchically. MIBs are accessed using a network-management protocol such as SNMP. They are comprised of managed objects and are identified by object identifiers. A managed object (sometimes called a MIB object, an object, or a MIB) is one of any number of specific characteristics of a managed device. Managed objects are comprised of one or more object instances, which are essentially variables. Two types of managed objects exist: scalar and tabular. Scalar objects define a single object instance. Tabular objects define multiple related object instances that are grouped in MIB tables. An example of a managed object is atInput, which is a scalar object that contains a single object instance, the integer value that indicates the total number of input AppleTalk packets on a router interface. An object identifier (or object ID) uniquely identifies a managed object in the MIB hierarchy. The MIB hierarchy can be depicted as a tree with a nameless root, the levels of which are assigned by different organizations. Below figure illustrates the MIB tree. The top-level MIB object IDs belong to different standards organizations, while lower-level object IDs are allocated by associated organizations. Vendors can define private branches that include managed objects for their own products. MIBs that have not been standardized typically are positioned in the experimental branch. The managed object atInput can be uniquely identified either by the object name—iso.identified-organization.dod.internet.private.enterprise.cisco.temporary variables.AppleTalk.atInput—or by the equivalent object descriptor, 1.3.6.1.4.1.9.3.3.1. 
SNMP Basic Commands 2008-12-23T05:09:25.395-08:00 Managed devices are monitored and controlled using four basic SNMP commands: read, write, trap, and traversal operations. The read command is used by an NMS to monitor managed devices. The NMS examines different variables that are maintained by managed devices. The write command is used by an NMS to control managed devices. The NMS changes the values of variables stored within managed devices. The trap command is used by managed devices to asynchronously report events to the NMS. When certain types of events occur, a managed device sends a trap to the NMS. Traversal operations are used by the NMS to determine which variables a managed device supports and to sequentially gather information in variable tables, such as a routing table. 
SNMP Basic Components 2008-12-23T05:07:10.896-08:00 An SNMP-managed network consists of three key components: managed devices, agents, and network-management systems (NMSs). A managed device is a network node that contains an SNMP agent and that resides on a managed network. Managed devices collect and store management information and make this information available to NMSs using SNMP. Managed devices, sometimes called network elements, can be routers and access servers, switches and bridges, hubs, computer hosts, or printers.An agent is a network-management software module that resides in a managed device. An agent has local knowledge of management information and translates that information into a form compatible with SNMP. An NMS executes applications that monitor and control managed devices. NMSs provide the bulk of the processing and memory resources required for network management. One or more NMSs must exist on any managed network.  
SNMP Introduction 2008-12-23T05:04:38.966-08:00 Simple Network Management ProtocolThe Simple Network Management Protocol (SNMP) is an application layer protocol that facilitates the exchange of management information between network devices. It is part of the Transmission Control Protocol/Internet Protocol (TCP/IP) protocol suite. SNMP enables network administrators to manage network performance, find and solve network problems, and plan for network growth. Two versions of SNMP exist: SNMP version 1 (SNMPv1) and SNMP version 2 (SNMPv2). Both versions have a number of features in common, but SNMPv2 offers enhancements, such as additional protocol operations. Standardization of yet another version of SNMP—SNMP Version 3 (SNMPv3)—is pending. This chapter provides descriptions of the SNMPv1 and SNMPv2 protocol operations. Below figure illustrates a basic network managed by SNMP.  
show ip bgp injected-paths 2008-11-11T07:33:00.647-08:00 show ip bgp injected-paths show ip bgp injected-pathsSyntax Description: This command has no arguments or keywords. Command Modes EXEC 
show ip bgp 2008-11-11T07:31:21.379-08:00 show ip bgp
bgp inject-map exist-map 2008-11-11T07:28:58.821-08:00 bgp inject-map exist-map To inject a more specific route into a Border Gateway Protocol (BGP) routing table, use the bgp inject-map exist-map command in address family or router configuration mode. To disable the conditional injection of a selected route, use the no form of this command. bgp inject-map {inject-map-name} exist-map {exist-map-name}[copy-attributes] no bgp inject-map {inject-map-name} exist-map {exist-map-name}[copy-attributes] Syntax: inject-map-name Description: Defines the prefixes that will be created and installed to the local BGP table. Syntax: exist-map-name Description: Specifies the prefix that the BGP speaker will track. Syntax: copy-attributes Description: (Optional) Configures the injected route to inherit the attributes of the aggregate route. Defaults: The BGP Conditional Route Injection feature is not enabled by default. Command Modes: Address family configuration, Router configuration Usage Guidelines: If the copy-attributes keyword is not specified when the bgp inject-map command is used, thecomponents will use the default attributes for locally originated routes. If the copy-attribute keyword is used, the components will inherit the same attributes as the aggregate route. To enable conditional route injection, the exist-map must contain both the match ip address prefix-list and match ip route-source prefix-list match clauses in the route map paragraph. Examples: The following example configures the router for conditional route injection: (config-router)# bgp inject-map map1 exist-map map2 copy-attributes Related Commands:
BGP Configuration Examples 2008-11-11T07:27:41.675-08:00 This following configuration example configures conditional route injection for the inject-map named ORIGINATE and the exist-map named LEARNED_PATH: router bgp 109 
BGP Troubleshooting 2008-11-11T07:26:38.121-08:00 The BGP Conditional Route Injection feature is based on the injection of a more specific prefix into theBGP routing table when a less specific prefix is present. If conditional route injection is not workingproperly, check the following: If conditional route injection is configured but does not occur, check for the existence of the aggregate prefix in the BGP routing table. The existence (or not) of the tracked prefix in the BGP If the aggregate prefix exists but conditional route injection does not occur, verify that the aggregate prefix is being received from the correct neighbor and the prefix list identifying that neighbor is a /32 match. Verify the injection (or not) of the more specific prefix using the show ip bgp injected-paths command. Verify that the prefix that is being injected is not outside of the scope of the aggregate prefix. Ensure that the inject route map is configured with the set ip address command and not the match ip address command. Monitoring and Maintaining BGP Conditional Route Injection To display BGP conditional advertisement information, use the following commands in EXEC mode, as needed: Command: Router# show ip bgp Purpose: Displays entries in the BGP routing table. Command: Router# show ip bgp injected-paths Purpose: Displays paths in the BGP routing table that were conditionally injected. Command: Router# show ip bgp neighbors Purpose: Displays information about the TCP and BGP connections to neighbors. 
Verifying BGP Conditional Route Injection 2008-11-11T07:25:07.596-08:00 To verify that the BGP Conditional Route Injection feature is configured correctly, use the show ip bgp or show ip bgp injected-paths command. Router# show ip bgp 172.16.0.0 The following sample output is similar to the output that will be displayed when the show ip bgp injected-routes command is entered: Router# show ip bgp injected-paths
Configuring BGP Conditional Route Injection 2008-11-11T07:23:38.022-08:00 The BGP Conditional Route Injection feature is supported by all platforms in Cisco IOS Release 12.2(14)S that support BGP:• Cisco 7200 series• Cisco 7400 series• Cisco 7500 seriesDetermining Platform Support Through Cisco Feature Navigator Cisco IOS software is packaged in feature sets that support specific platforms. To get updated information regarding platform support for this feature, access Cisco Feature Navigator. Cisco Feature Navigator dynamically updates the list of supported platforms as new platform support is added for the feature. Cisco Feature Navigator is a web-based tool that enables you to determine which Cisco IOS software images support a specific set of features and which features are supported in a specific Cisco IOS image.You can search by feature or release. Under the release section, you can compare releases side by side to display both the features unique to each software release and the features in common.See the following section for configuration tasks for the BGP Conditional Route Injection feature. Each task in the list is identified as either required or optional.• Configuring BGP Conditional Route Injection (required)• Verifying BGP Conditional Route Injection (optional)To configure the BGP Conditional Route Injection feature, use the following commands beginning in global configuration mode:CommandPurposeStep 1Router(config)# router bgp as-numberPlaces the router in router configuration mode, and configures the router to run a BGP process.Step 2Router(config-router)# bgp inject-map ORIGINATEexist-map LEARNED_PATHConfigures the inject-map named ORIGINATE and the exist-map named LEARNED_PATH for conditional route injection.Step 3Router(config-router)# exitExits router configuration mode, and enters global configuration mode.Step 4Router(config)# route-map LEARNED_PATH permitsequence-numberConfigures the route map namedLEARNED_PATH.Step 5Router(config-route-map)# match ip address prefix-listROUTESpecifies the aggregate route to which a more specific route will be injected.Step 6Router(config-route-map# match ip route-sourceprefix-list ROUTE_SOURCEConfigures the prefix list namedROUTE_SOURCE to redistribute the source of the route.Note: The route source is the neighbor address that is configured with the neighbor remote-as command. The tracked prefix must come from this neighbor in order for conditional route injection to occur.Step 7Router(config-route-map)# exitExits route-map configuration mode, and enters global configuration mode.Step 8Router(config)# route-map ORIGINATE permit 10Configures the route map named ORIGINATE.Step 9Router(config-route-map)# set ip address prefix-list ORIGINATED_ROUTESSpecifies the routes to be injected.Step 10Router(config-route-map)# set community community-attribute additiveConfigures the community attribute of the injected routes.Step 11Router(config-route-map)# exitExits route-map configuration mode, and enters global configuration mode.Step 12Router(config)# ip prefix-list ROUTE permit10.1.1.0/24Configures the prefix list named ROUTE to permit routes from network 10.1.1.0/24.Step 13Router(config)# ip prefix-list ORIGINATED_ROUTESpermit 10.1.1.0/25Configures the prefix list namedORIGINATED_ROUTES to permit routes from network 10.1.1.0/25.Step 14Router(config)# ip prefix-list ORIGINATED_ROUTESpermit 10.1.1.128/25Configures the prefix list namedORIGINATED_ROUTES to permit routes from network 10.1.1.0/25.Step 15Router(config)# ip prefix-list ROUTE_SOURCE permit10.2.1.1/32Configures the prefix list namedROUTE_SOURCE to permit routes from network 10.2.1.1/32.Note: The route source prefix list must be configured with a /32 [...]
BGP Route Flap Dampening 2008-11-11T07:21:18.893-08:00 Route dampening (introduced in Cisco IOS version 11.0) is a mechanism to minimize the instability caused by route flapping and oscillation over the network. To accomplish this, criteria are defined to identify poorly behaved routes. A route which is flapping gets a penalty for each flap (1000). As soon as the cumulative penalty reaches a predefined "suppress−limit", the advertisement of the route will be suppressed. The penalty will be exponentially decayed based on a preconfigured "half−time". Once the penalty decreases below a predefined "reuse−limit", the route advertisement will be un−suppressed.Routes, external to an AS, learned via IBGP will not be dampened. This is to avoid the IBGP peers having higher penalty for routes external to the AS.The penalty will be decayed at a granularity of 5 seconds and the routes will be un−suppressed at a granularity of 10 seconds. The dampening information is kept until the penalty becomes less than half of "reuse−limit" , at that point the information is purged from the router.Initially, dampening will be off by default. This might change if there is a need to have this feature enabled by default. The following are the commands used to control route dampening:bgp dampening (will turn on dampening)no bgp dampening (will turn off dampening)bgp dampening (will change the half−life−time)A command that sets all parameters at the same time is:bgp dampening (range is 1−45 min, current default is 15 min) (range is 1−20000, default is 750) (range is 1−20000, default is 2000) (maximum duration a route can be suppressed, range is 1−255, default is 4 times half−life−time)RTB#hostname RTBinterface Serial0ip address 203.250.15.2 255.255.255.252interface Serial1ip address 192.208.10.6 255.255.255.252router bgp 100bgp dampeningnetwork 203.250.15.0neighbor 192.208.10.5 remote−as 300RTD#hostname RTDinterface Loopback0ip address 192.208.10.174 255.255.255.192interface Serial0/0ip address 192.208.10.5 255.255.255.252router bgp 300network 192.208.10.0neighbor 192.208.10.6 remote−as 100RTB is configured for route dampening with default parameters. Assuming the EBGP link to RTD is stable, RTB's BGP table would look like this:RTB#show ip bgpBGP table version is 24, local router ID is 203.250.15.2 Status codes: ssuppressed, d damped, h history, * valid, > best, i − internal Origincodes: i − IGP, e − EGP, ? − incompleteNetworkNext HopMetricLocPrfWeightPath*>192.208.10.0192.208.10.500300 i*>203.250.15.00.0.0.0032768iIn order to simulate a route flap, use clear ip bgp 192.208.10.6 on RTD. RTB's BGP table will look like this:RTB#show ip bgpBGP table version is 24, local router ID is 203.250.15.2 Status codes: ssuppressed, d damped, h history, * valid, > best, i − internal Origincodes: i − IGP, e − EGP, ? − incompleteNetworkNext HopMetricLocPrfWeightPathh192.208.10.0192.208.10.500300 i*>203.250.15.00.0.0.0032768iThe BGP entry for 192.208.10.0 has been put in a "history" state. Which means that we do not have a best path to the route but information about the route flapping still exists.RTB#show ip bgp 192.208.10.0BGP routing table entry for 192.208.10.0 255.255.255.0, version 25Paths: (1 available, no best path)300 (history entry)192.208.10.5 from 192.208.10.5 (192.208.10.174)Origin IGP, metric 0, externalDampinfo: penalty 910, flapped 1 times in 0:02:03The route has been given a penalty for flapping but the penalty is still below the "suppress limit" (default is 2000). The route is not yet suppressed. If the route flaps few more times we will see the following:RTB#show ip bgpBGP table version is 32, [...]
BGP RR and Conventional BGP Speakers 2008-11-11T07:19:53.292-08:00  It is normal in an AS to have BGP speakers that do not understand the concept of route reflectors. We will call these routers conventional BGP speakers. The route reflector scheme will allow such conventional BGP speakers to coexist. These routers could be either members of a client group or a non−client group. This would allow easy and gradual migration from the current IBGP model to the route reflector model. One could start creating clusters by configuring a single router as RR and making other RRs and their clients normal IBGP peers. Then more clusters could be created gradually. In the above diagram, RTD, RTE and RTF have the concept of route reflection. RTC, RTA and RTB are what we call conventional routers and cannot be configured as RRs. Normal IBGP mesh could be done between these routers and RTD. Later on, when we are ready to upgrade, RTC could be made a RR with clients RTA and RTB. Clients do not have to understand the route reflection scheme; it is only the RRs that would have to be upgraded. The following is the configuration of RTD and RTC: RTD# When we are ready to upgrade RTC and make it a RR, we would remove the IBGP full mesh and have RTA and RTB become clients of RTC. Avoiding Looping of Routing Information We have mentioned so far two attributes that are used to prevent potential information looping: originator−id and cluster−list. Another means of controlling loops is to put more restrictions on the set clause of out−bound route−maps. The set clause for out−bound route−maps does not affect routes reflected to IBGP peers. More restrictions are also put on nexthop−self, which is a per neighbor configuration option. When used on RRs the nexthop−self will only affect the nexthop of EBGP learned routes because the nexthop of reflected routes should not be changed. 
BGP Multiple RRs within a Cluster 2008-11-11T07:18:30.104-08:00 Usually, a cluster of clients will have a single RR. In this case, the cluster will be identified by the router ID of the RR. In order to increase redundancy and avoid single points of failure, a cluster might have more than one RR. All RRs in the same cluster need to be configured with a 4 byte cluster−id so that a RR can recognize updates from RRs in the same cluster.A cluster−list is a sequence of cluster−ids that the route has passed. When a RR reflects a route from its clients to non−clients outside of the cluster, it will append the local cluster−id to the cluster−list. If this update has an empty cluster−list the RR will create one. Using this attribute, a RR can identify if the routing information is looped back to the same cluster due to poor configuration. If the local cluster−id is found in the cluster−list, the advertisement will be ignored.In the above diagram, RTD, RTE, RTF and RTH belong to one cluster with both RTD and RTH being RRs for the same cluster. Note the redundancy in that RTH has a fully meshed peering with all the RRs. In case RTD goes down, RTH will take its place. The following are the configuration of RTH, RTD, RTF and RTC:RTH#router bgp 100neighbor 4.4.4.4 remote−as 100neighbor 5.5.5.5 remote−as 100neighbor 5.5.5.5 route−reflector−clientneighbor 6.6.6.6 remote−as 100neighbor 6.6.6.6 route−reflector−clientneighbor 7.7.7.7 remote−as 100neighbor 3.3.3.3 remote−as 100neighbor 9.9.9.9 remote−as 300bgp route−reflector 10 (This is the cluster−id)RTD#router bgp 100neighbor 10.10.10.10 remote−as 100neighbor 5.5.5.5 remote−as 100neighbor 5.5.5.5 route−reflector−clientneighbor 6.6.6.6 remote−as 100neighbor 6.6.6.6 route−reflector−clientneighbor 7.7.7.7 remote−as 100neighbor 3.3.3.3 remote−as 100neighbor 11.11.11.11 remote−as 400bgp route−reflector 10 (This is the cluster−id)RTF#router bgp 100neighbor 10.10.10.10 remote−as 100neighbor 4.4.4.4 remote−as 100neighbor 13.13.13.13 remote−as 500RTC#router bgp 100neighbor 1.1.1.1 remote−as 100neighbor 1.1.1.1 route−reflector−clientneighbor 2.2.2.2 remote−as 100neighbor 2.2.2.2 route−reflector−clientneighbor 4.4.4.4 remote−as 100neighbor 7.7.7.7 remote−as 100neighbor 10.10.10.10 remote−as 100neighbor 8.8.8.8 remote−as 200Note that we did not need the cluster command for RTC because only one RR exists in that cluster. An important thing to note, is that peer−groups were not used in the above configuration. If the clients inside a cluster do not have direct IBGP peers among one another and they exchange updates through the RR, peer−goups should not be used. If peer groups were to be configured, then a potential withdrawal to the source of a route on the RR would be sent to all clients inside the cluster and could cause problems.The router sub−command bgp client−to−client reflection is enabled by default on the RR. If BGP client−to−client reflection were turned off on the RR and redundant BGP peering was made between the clients, then using peer groups would be alright.[...]
BGP Route Reflectors 2008-11-11T07:16:51.176-08:00 Another solution for the explosion of IBGP peering within an autonomous system is Route Reflectors (RR).As demonstrated in the Internal BGP section, a BGP speaker will not advertise a route learned via another IBGP speaker to a third IBGP speaker. By relaxing this restriction a bit and by providing additional control, we can allow a router to advertise (reflect) IBGP learned routes to other IBGP speakers. This will reduce the number of IBGP peers within an AS.In normal cases, a full IBGP mesh should be maintained between RTA, RTB and RTC within AS100. By utilizing the route reflector concept, RTC could be elected as a RR and have a partial IBGP peering with RTA and RTB. Peering between RTA and RTB is not needed because RTC will be a route reflector for the updates coming from RTA and RTB.neighbor route−reflector−clientThe router with the above command would be the RR and the neighbors pointed at would be the clients of that RR. In our example, RTC would be configured with the neighbor route−reflector−client command pointing at RTA and RTB's IP addresses. The combination of the RR and its clients is called a cluster. RTA, RTB and RTC above would form a cluster with a single RR within AS100.Other IBGP peers of the RR that are not clients are called non−clients.An autonomous system can have more than one route reflector; a RR would treat other RRs just like any other IBGP speaker. Other RRs could belong to the same cluster (client group) or to other clusters. In a simple configuration, the AS could be divided into multiple clusters, each RR will be configured with other RRs as non−client peers in a fully meshed topology. Clients should not peer with IBGP speakers outside their cluster.Consider the above diagram. RTA, RTB and RTC form a single cluster with RTC being the RR. According to RTC, RTA and RTB are clients and anything else is a non−client. Remember that clients of an RR are pointed at using the neighbor route−reflector−client command. The same RTD is the RR for its clients RTE and RTF; RTG is a RR in a third cluster. Note that RTD, RTC and RTG are fully meshed but routers within a cluster are not. When a route is received by a RR, it will do the following depending on the peer type:Route from a non−client peer: reflect to all the clients within the cluster.Route from a client peer: reflect to all the non−client peers and also to the client peers.Route from an EBGP peer: send the update to all client and non−client peers.The following is the relative BGP configuration of routers RTC, RTD and RTB:RTC#router bgp 100neighbor 2.2.2.2 remote−as 100neighbor 2.2.2.2 route−reflector−clientneighbor 1.1.1.1 remote−as 100neighbor 1.1.1.1 route−reflector−clientneighbor 7.7.7.7 remote−as 100neighbor 4.4.4.4 remote−as 100neighbor 8.8.8.8 remote−as 200RTB#router bgp 100neighbor 3.3.3.3 remote−as 100neighbor 12.12.12.12 remote−as 300RTD#router bgp 100neighbor 6.6.6.6 remote−as 100neighbor 6.6.6.6 route−reflector−clientneighbor 5.5.5.5 remote−as 100neighbor 5.5.5.5 route−reflector−clientneighbor 7.7.7.7 remote−as 100neighbor 3.3.3.3 remote−as 100As the IBGP learned routes are reflected, it is possible to have the routing information loop. The Route Reflector scheme has a few methods to avoid this:Originator−id: this is an optional, non transitive BGP attribute that is four bytes long and is created by a RR. This attribute will carry the router−id (RID) of the originator of the route in the local AS. Thus, due to poor configuration,[...]
BGP Confederation 2008-11-11T07:15:42.279-08:00 BGP confederation is implemented in order to reduce the IBGP mesh inside an AS. The trick is to divide an AS into multiple ASs and assign the whole group to a single confederation. Each AS by itself will have IBGP fully meshed and has connections to other AS's inside the confederation. Even though these ASs will have EBGP peers to ASs within the confederation, they exchange routing as if they were using IBGP; next hop, metric and local preference information are preserved. To the outside world, the confederation (the group of ASs) will look like a single AS.To configure a BGP confederation use the following:bgp confederation identifier autonomous−systemThe confederation identifier will be the AS number of the confederation group. The group of ASs will look to the outside world as one AS with the AS number being the confederation identifier.Peering within the confederation between multiple ASs is done via the following command:bgp confederation peers autonomous−system [autonomous−system]The following is an example of confederation:Let us assume that you have an autonomous system 500 consisting of nine BGP speakers (other non BGP speakers exist also, but we are only interested in the BGP speakers that have EBGP connections to other ASs). If you want to make a full IBGP mesh inside AS500 then you would need nine peer connections for each router, 8 IBGP peers and one EBGP peer to external ASs.By using confederation we can divide AS500 into multiple ASs: AS50, AS60 and AS70. We give the AS a confederation identifier of 500. The outside world will see only one AS500. For each AS50, AS60 and AS70 we define a full mesh of IBGP peers and we define the list of confederation peers using the bgp confederation peers command.Let's look at a sample configuration of routers RTC, RTD and RTA. Note that RTA has no knowledge of ASs 50, 60 or 70. RTA has only knowledge of AS500.RTC#router bgp 50bgp confederation identifier 500bgp confederation peers 60 70neighbor 128.213.10.1 remote−as 50 (IBGP connection within AS50)neighbor 128.213.20.1 remote−as 50 (IBGP connection within AS50)neighbor 129.210.11.1 remote−as 60 (BGP connection with confederation peer 60)neighbor 135.212.14.1 remote−as 70 (BGP connection with confederation peer 70)neighbor 5.5.5.5 remote−as 100 (EBGP connection to external AS100)RTD#router bgp 60bgp confederation identifier 500bgp confederation peers 50 70neighbor 129.210.30.2 remote−as 60 (IBGP connection within AS60)neighbor 128.213.30.1 remote−as 50(BGP connection with confederation peer 50)neighbor 135.212.14.1 remote−as 70 (BGP connection with confederation peer 70)neighbor 6.6.6.6 remote−as 600 (EBGP connection to external AS600)RTA#router bgp 100neighbor 5.5.5.4 remote−as 500 (EBGP connection to confederation 500)[...]
BGP CIDR 2008-11-11T07:13:47.423-08:00 CIDR and Aggregate AddressesOne of the main enhancements of BGP4 over BGP3 is Classless Interdomain Routing (CIDR). CIDR or supernetting is a new way of looking at IP addresses. There is no notion of classes anymore (class A, B or C).For example, network 192.213.0.0 which used to be an illegal class C network is now a legal supernet represented by 192.213.0.0/16 where the 16 is the number of bits in the subnet mask counting from the far left of the IP address. This is similar to 192.213.0.0 255.255.0.0.Aggregates are used to minimize the size of routing tables. Aggregation is the process of combining the characteristics of several different routes in such a way that a single route can be advertised. In the example below, RTB is generating network 160.10.0.0. We will configure RTC to propagate a supernet of that route 160.0.0.0 to RTA.RTB#router bgp 200neighbor 3.3.3.1 remote−as 300network 160.10.0.0#RTCrouter bgp 300neighbor 3.3.3.3 remote−as 200neighbor 2.2.2.2 remote−as 100network 170.10.0.0aggregate−address 160.0.0.0 255.0.0.0RTC will propagate the aggregate address 160.0.0.0 to RTA.Aggregate CommandsThere is a wide range of aggregate commands. It is important to understand how each one works in order to have the desired aggregation behavior.The first command is the one used in the previous example:aggregate−address address maskThis will advertise the prefix route, and all of the more specific routes. The command aggregate−address 160.0.0.0 will propagate an additional network 160.0.0.0 but will not prevent 160.10.0.0 from being also propagated to RTA. The outcome of this is that both networks 160.0.0.0 and 160.10.0.0 have been propagated to RTA. This is what we mean by advertising the prefix and the more specific route.Please note that you can not aggregate an address if you do not have a more specific route of that address in the BGP routing table.For example, RTB can not generate an aggregate for 160.0.0.0 if it does not have a more specific entry of 160.0.0.0 in its BGP table. The more specific route could have been injected into the BGP table via incoming updates from other ASs, from redistributing an IGP or static into BGP or via the network command (network 160.10.0.0).In case we would like RTC to propagate network 160.0.0.0 only and NOT the more specific route then we would have to use the following:aggregate−address address mask summary−onlyThis will a advertise the prefix only; all the more specific routes are suppressed.The command aggregate 160.0.0.0 255.0.0.0 summary−only will propagate network 160.0.0.0 and will suppress the more specific route 160.10.0.0.Please note that if we are aggregating a network that is injected into our BGP via the network statement (ex: network 160.10.0.0 on RTB) then the network entry is always injected into BGP updates even though we are using "the aggregate summary−only" command. The upcoming CIDR example discusses this situation.aggregate−address address mask as−setThis advertises the prefix and the more specific routes but it includes as−set information in the path information of the routing updates.aggregate 129.0.0.0 255.0.0.0 as−setThis command will be discussed in an example by itself in the following sections.In case we would like to suppress more specific routes when doing the aggregation we can define a route map and apply it to the aggregates. This will allow us to be selective about which more specific routes to suppress.aggregate−address addres[...]
BGP Peer Groups 2008-11-11T07:12:00.473-08:00  A BGP peer group, is a group of BGP neighbors with the same update policies. Update policies are usually set by route maps, distribute−lists and filter−lists, etc. Instead of defining the same policies for each separate neighbor, we define a peer group name and we assign these policies to the peer group. Members of the peer group inherit all of the configuration options of the peer group. Members can also be configured to override these options if these options do not affect outbound updates; you can only override options set on the inbound. To define a peer group use the following: neighbor peer−group−name peer−groupIn the following example we will see how peer groups are applied to internal and external BGP neighbors. RTC#In the above configuration, we have defined a peer group named internalmap and we have defined some policies for that group, such as a route map SETMETRIC to set the metric to 5 and two different filter lists 1 and 2. We have applied the peer group to all internal neighbors RTE, RTF and RTG. We have defined a separate filter−list 3 for neighbor RTE, and this will override filter−list 2 inside the peer group. Note that we could only override options that affect inbound updates. Now, let us look at how we can use peer groups with external neighbors. In the same diagram we will configure RTC with a peer−group externalmap and we will apply it to external neighbors. RTC#Note that in the above configs we have defined the remote−as statements outside of the peer group because we have to define different external ASs. Also we did an override for the inbound updates of neighbor 1.1.1.2 by assigning filter−list 3. 
BGP Neighbors 2008-11-11T07:10:30.463-08:00 BGP Neighbors and Route MapsThe neighbor command can be used in conjunction with route maps to perform either filtering or parameter setting on incoming and outgoing updates.Route maps associated with the neighbor statement have no affect on incoming updates when matching based on the IP address:neighbor ip−address route−map route−map−nameAssume in the above diagram we want RTC to learn from AS200 about networks that are local to AS200 and nothing else. Also, we want to set the weight on the accepted routes to 20. We can achieve this with a combination of neighbor and as−path access lists.RTC#router bgp 300network 170.10.0.0neighbor 3.3.3.3 remote−as 200neighbor 3.3.3.3 route−map stamp inroute−map stampmatch as−path 1set weight 20ip as−path access−list 1 permit ^200$Any updates that originate from AS200 have a path information that starts with 200 and ends with 200 and will be permitted. Any other updates will be dropped.Assume that we want the following:Updates originating from AS200 to be accepted with weight 20.Updates originating from AS400 to be dropped.Other updates to have a weight of 10.RTC#router bgp 300network 170.10.0.0neighbor 3.3.3.3 remote−as 200neighbor 3.3.3.3 route−map stamp inroute−map stamp permit 10match as−path 1set weight 20route−map stamp permit 20match as−path 2set weight 10ip as−path access−list 1 permit ^200$ip as−path access−list 2 permit ^200 600 .*The above statement will set a weight of 20 for updates that are local to AS200, and will set a weight of 10 for updates that are behind AS400 and will drop updates coming from AS400.Use of set as−path prepend CommandIn some situations we are forced to manipulate the path information in order to manipulate the BGP decision process. The command that is used with a route map is:set as−path prepend ...Suppose in the above diagram that RTC is advertising its own network 170.10.0.0 to two different ASs:AS100 and AS200. When the information is propagated to AS600, the routers in AS600 will have network reachability information about 150.10.0.0 via two different routes, the first route is via AS100 with PATH (100, 300) and the second one is via AS400 with PATH (400, 200,300). Assuming that all other attributes are the same AS600 will pick the shortest path and will choose the route via AS100.AS300 will be getting all its traffic via AS100. If we want to influence this decision from the AS300 end we can make the PATH through AS100 look like it is longer than the PATH going through AS400. We can do this by prepending autonomous system numbers to the existing path info advertised to AS100. A common practice is to repeat our own AS number using the following:RTC#router bgp 300network 170.10.0.0neighbor 2.2.2.2 remote−as 100neighbor 2.2.2.2 route−map SETPATH outroute−map SETPATHset as−path prepend 300 300Because of the above configuration, AS600 will receive updates about 170.10.0.0 via AS100 with a PATH information of: (100, 300, 300, 300) which is longer than (400, 200, 300) received from AS100.[...] |
||||||||||||||||||||||||||||||||||||||||||||||||||||
http://www.networknowledge.blogspot.com/rss.xml
Copyright 2006-2010 Feedage.com LLC
Privacy policy - Sitemap - Press - Terms of Service - Copyright information - Contact Us - About Us - Feedage
Language Detection Powered by
Privacy policy - Sitemap - Press - Terms of Service - Copyright information - Contact Us - About Us - Feedage
Language Detection Powered by