HP 5500 Ei 5500 Si Switch Series Configuration Guide
Have a look at the manual HP 5500 Ei 5500 Si Switch Series Configuration Guide online for free. It’s possible to download the document as PDF or print. UserManuals.tech offer 1114 HP manuals and user’s guides for free. Share the user manual or guide on Facebook, Twitter or Google+.
192
Use the AS_PATH attribute for route selection and filtering. BGP gives priority to the route with the
shortest AS_PATH length, if other factors are the same. As shown in Figure 76, the BGP rout
er in
AS50 gives priority to the route passing AS40 for sending data to the destination 8.0.0.0.
In some applications, you can apply a routing policy to control BGP route selection by modifying
the AS_PATH length.
By configuring an AS path filtering list, you can fi lter routes based on AS numbers contained in the
AS_PATH attribute.
• NEXT_HOP
Different from IGP, the NEXT_HOP attribute may not be the IP address of a directly connected
router. It involves the following types of values, as shown in Figure 77.
{ When advertising a self-originated route to an EBGP peer, a BGP speaker sets the NEXT_HOP
for the route to the address of its sending interface.
{ When sending a received route to an EBGP pe er, a BGP speaker sets the NEXT_HOP for the
route to the address of the sending interface.
{ When sending a route received from an EBGP pe er to an IBGP peer, a BGP speaker does not
modify the NEXT_HOP attribute. If load-balancing is configured, the NEXT_HOP attribute of
the equal-cost routes is modified. For load-balancing information, see BGP route selection.
Figure 77 NEXT_HOP at
tribute
• MED (MULTI_EXIT_DISC)
The MED attribute is exchanged between two neighb oring ASs, each of which does not advertise
the attribute to any other AS.
S i m i l a r t o m e t r i c s u s e d b y I G P , M E D i s u s e d t o d e termine the best route for traffic going into an AS.
When a BGP router obtains multiple routes to the sa me destination, but with different next hops, it
considers the route with the smallest MED value th e best route given that other conditions are the
same. As shown in Figure 78, traffic from AS10 to
AS20 travels through Router B that is selected
according to MED.
193 Figure 78 MED attribute In general, BGP compares MEDs of routes received from the same AS only. NOTE: The current implementation supports using the compare-different-as-med command to force BGP to compare MED values of routes received from different ASs. • LOC AL _PR EF The LOCAL_PREF attribute is exchanged between IBGP peers only; therefore, it is not advertised to any other AS. It indicates the priority of a BGP router. LOCAL_PREF is used to determine the best route fo r traffic leaving the local AS. When a BGP router obtains from several IBGP peers multiple routes to the same destination, but with different next hops, it considers the route with the highest LOCAL_PREF value as the best route. As shown in Figure 79 , traffi c from AS20 to AS10 tr avels through Router C that is selected according to LOCAL_PREF. Figure 79 LOCAL_PREF attribute • COMMUNITY The COMMUNITY attribute is a group of specific data. A route can carry one or more COMMUNITY attribute values (each of which is re presented by a four-byte integer). The receiving router processes the route (for example, determin ing whether to advertise the route and the scope for advertising the route) based on the COMMUNITY attribute values. This simplifies routing policy EBGPRouter B Router A Router CRouter D D = 8.0.0.0 Next_hop = 3.1.1.1 Local_pref = 200 IBGPIBGP IBGP EBGP 2.1.1.1 8.0.0.0 Local_pref = 100 Next_hop = 2.1.1.1 Local_pref = 100 Local_pref = 200 3.1.1.1 AS 20 AS 10
194
usage and facilitates management and maintenance. Well-known community attributes are as
follows:
{ Internet —By default, all routes belong to the Internet community. Routes with this attribute can
be advertised to all BGP peers.
{ No_Export —After received, routes with this attribute cannot be advertised out the local AS or
out the local confederation, but can be advertised to other sub-ASs in the confederation. For
confederation information, see Settlements for problems in large scale BGP networks .
{ No_Advertise —After received, routes with this attribute cannot be advertised to other BGP
peers.
{ No_Export_Subconfed—After received, routes with this attribute cannot be advertised out the
local AS or other ASs in the local confederation.
BGP route selection
Route selection rules
BGP discards routes with unreachable NEXT_HOPs. If multiple routes to the same destination are
available, BGP selects the best route in the following sequence:
1. The route with the highest Preferred_value
2. The route with the highest LOCAL_PREF
3. The route originated by the local router
4. The route with the shortest AS-PATH
5. The IGP, EGP, or INCOMPLETE route in turn
6. The route with the lowest MED value
7. The route learned from EBGP, confederation, or IBGP in turn
8. The route with the smallest next hop metric
9. The route with the shortest CLUSTER_LIST
10. The route with the smallest ORIGINATOR_ID
11. The route advertised by the router with the smallest router ID
12. The route advertised by the peer with the lowest IP address
CLUSTER_IDs of route reflectors form a CLUSTER_LIST. If a route reflector receives a route that contains its
own CLUSTER ID in the CLUSTER_LIST, the router discards the route to avoid routing loops.
If load balancing is configured, the system selects available routes to implement load balancing.
Route selection with BGP load balancing
The next hop of a BGP route may not be directly connected. One of the reasons is next hops in routing
information exchanged between IBGPs are not modified. The BGP router needs to find the directly
connected next hop via IGP. The matching route with the direct next hop is called the recursive route.
The process of finding a recursive route is route recursion.
The system supports BGP load balancing based on route recursion. If multiple recursive routes to the
same destination are load balanced (suppose three direct next hop addresses), BGP generates the same
number of next hops to forward packets. BGP load balancing based on route recursion is always
enabled by the system rather than configured using commands.
BGP differs from IGP in the implementation of load balancing in the following ways:
195 • IGP routing protocols such as RIP and OSPF comp ute metrics of routes, and then implement load balancing over routes with the same metric and to the same destination. The route selection criterion is metric. • BGP has no route computation algorithm, so it cannot implement load balancing according to metrics of routes. However, BGP has abundant route selection rules, through which, it selects available routes for load balancing and adds load balancing to route selection rules. BGP implements load balancing only on routes th at have the same AS_PATH, ORIGIN, LOCAL_PREF, and MED. BGP load balancing is applicable between EBGP peers, between IBGP peers, and between confederations. If multiple routes to the same destination are availa ble, BGP selects a configurable number of routes for load balancing. Figure 80 Network diagram for BGP load balancing In the above figure, Router D and Router E are IBGP peers of Router C. Router A and Router B both advertise a route destined for the same destination to Router C. If load balancing is configured and the two routes have the same AS_PATH attribute, ORIGIN attribute, LOCAL_PREF and MED, Router C installs both the two routes to its route table for load balanci ng. After that, Router C forwards to Router D and Router E the route that has AS_PATH unchanged bu t has NEXT_HOP changed to Router C; other BGP transitive attributes are those of the best route. BGP route advertisement rules The current BGP implementation supports the following route advertisement rules: • When multiple feasible routes to a destination exist, the BGP speaker advertises only the best route to its peers. • A BGP speaker only advertises routes that it uses. • A BGP speaker advertises routes learned through EB GP to all BGP peers, including both EBGP and IBGP peers. • A BGP speaker does not advertise routes from an IBGP peer to other IBGP peers. • A BGP speaker advertises routes learned through IBGP to EBGP peers. If BGP and IGP synchronization is disabled, those routes are advert ised to EBGP peers directly. If the feature is enabled, only after IGP advertises those routes , can BGP advertise the routes to EBGP peers.
196 • A BGP speaker advertises all routes to a newly connected peer. IBGP and IGP synchronization Routing information synchronization between IBGP an d IGP avoids giving wrong directions to routers outside of the local AS. If a non-BGP router works in an AS, it can discar d a packet because a destination is unreachable. As shown in Figure 81, R outer E has learned a route of 8.0.0.0/8 from Router D via BGP. Router E then sends a packet to 8.0.0.0/8 through Router D, which finds from its routing table that Router B is the next hop (configured using the peer next-hop-local command). Because Router D has learned the route to Router B via IGP, it forwards the packet to Router C through route recursion. Router C is unaware of the route 8.0.0.0/8, so it discards the packet. Figure 81 IBGP and IGP synchronization For this example, if synchronization is enabled, and the route 8.0.0.0/24 received from Router B is available in its IGP routing table, Router D adds the route into its BGP routing table and advertises the route to the EBGP peer. You can disable the synchronization feature in the following situations: • The local AS is not a transitive AS (AS20 is a transitive AS in the above figure). • Routers in the local AS are IBGP fully meshed. Settlements for problems in large scale BGP networks Route summarization Route summarization can reduce the routing table size on a large network, and allow BGP routers to advertise only summary routes. The system supports both manual and automatic route summarization. Manual route summarization allows you to determine the attribute of a summary route and whether to advertise the route. Route dampening BGP route dampening solves the issue of route instability such as route flaps—a route comes up and disappears in the routing table frequently. When a route flap occurs, the routing protocol send s an update to its neighbor, and then the neighbor must recalculate routes and modify the routing table. Frequent route flaps consume large bandwidth and CPU resources, which could affect network operation.
197 In most cases, BGP is used in complex networks, where route changes are more frequent. To solve the problem caused by route flaps, BGP route dampening is used to suppress unstable routes. BGP route dampening, as shown in Figure 82, u ses a penalty value to judge the stability of a route. The bigger the value, the less stable th e route. Each time a route flap occurs, BGP adds a penalty value (1000, which is a fixed number and cannot be changed) to the route. When the penalty value of the route exceeds the suppress value, the route is suppressed from being added into the routing table or being advertised to other BGP peers. The penalty value of the suppressed route will decrease to half of the suppress value after a period of time. This period is called Half-life. When the value decr eases to the reusable threshold value, the route is added into the routing table and advertised to other BGP peers. Figure 82 BGP route dampening Peer group You can organize BGP peers with the same attributes into a group to simplify their configurations. When a peer joins the peer group, the peer obtains the same configuration as the peer group. If the configuration of the peer group is changed, the configuration of group members is changed. When a peer is added into a peer group, the peer has the same route update policy as the peer group to improve route distribution efficiency. If an option is configured for both a peer and its peer group, the last configuration takes effect. Community A peer group provides each peer with the same policy. A community provides a group of BGP routers in several ASs with the same policy. Community is a path attribute advertised between BGP peers without being limited by AS. A BGP router can modify the community attribute for a route before sending it to other peers. Besides using well-known community attributes, you can define extended community attributes by using a community list to define a routing policy.
198 Route reflector I BG P pe ers must be fu l ly mes he d to mai ntai n c onne ctivi t y. I f n routers exist i n an AS, the nu mber of I BG P connections is n (n-1)/2, and large amounts of network and CPU resources are consumed. Using route reflectors can resolve this issue. In an AS, a router acts as a route reflector, and other routers act as clients connecting to the route reflector. The route reflector forwards routing information between clients, so BGP sessions between clients need not be established. A router that is neither a route reflector nor a client is a non-client, which, as shown in Figure 83, mu st establish BGP sessions to the route reflector and other non-clients. Figure 83 Network diagram for a route reflector The route reflector and clients form a cluster. In some cases, you can configure more than one route reflector in a cluster to improve network reliability and prevent a single point of failure, as shown in the following figure. The configured route reflectors must have the same Cluster_ID in order to avoid routing loops. Figure 84 Network diagram for route reflectors When the BGP routers in an AS are fully meshed, route reflection is unnecessary because it consumes more bandwidth resources. You can use related commands to disable route reflection.
199 NOTE: After route reflection is disabled between clients, routes can still be reflected between a client and a non-client. Confederation Confederation is another method to manage growing IB G P c o n n e c t i o n s i n A S s . T h i s m e t h o d s p l i t s a n A S into multiple sub-ASs. In each sub-AS, IBGP peers are fully meshed, and, as shown in Figure 85, in tra-confederation EBGP connections are established between sub-ASs. Figure 85 Confederation network diagram A non-confederation BGP speaker is not required to know sub-ASs in the confederation. The ID of the confederation is the number of the AS. In the above figure, AS 200 is the confederation ID. The deficiency of confederation is as follows: • When changing an AS into a confederation, you must reconfigure your routers. • The topology is changed. In large-scale BGP networks, both route reflector and confederation can be used. BGP GR Graceful Restart (GR) ensures the continuity of packet forwarding when BGP restarts or an active/standby switchover occurs: • GR Restarter —Graceful restarting router. It must be GR capable. • GR Helper —A neighbor of the GR Restarter. It helps the GR Restarter to complete the GR process. The following describes the BGP routing convergence process: 1. To establish a BGP session with a peer, a BGP GR Restarter sends an Open message with GR capability to the peer. 2. Upon receipt of this message, the peer is aware that the sending router is capable of Graceful Restart, and sends an Open message with GR C apability to the GR Restarter to establish a GR AS 100EBGP IBGPIBGP IBGP EBGP EBGP AS 65002 AS 65003 AS 65004 AS 200
200 session. If neither party has the GR capability, the session established between them will not be GR capable. 3. W h e n a n a c t i v e / s t a n d b y s w i t c h o v e r o c c u r s o n t h e G R R e s t a r t e r , s e s s i o n s o n i t w i l l g o d o w n . T h e n , GR-capable peers will mark all routes associated with the GR Restarter as stale. However, during the configured GR Time, they still use these routes for packet forwarding. 4. After the restart is completed, the GR Restarter will reestablish GR sessions with its peers and send a new GR message, notifying the completion of re start. Routing information is exchanged between them for the GR Restarter to create a new rout ing table and forwarding table and have stale routing information removed. Then the BGP routing convergence is complete. MP-BGP Overview BGP-4 supports IPv4 unicasts, but does not support other network layer protocols, such as IPv6. To support more network layer protocols, IETF exte nded BGP-4 by introducing Multiprotocol Extensions for BGP-4 (MP-BGP) in RFC 4760. Routers supporting MP-BGP can communicate with routers not supporting MP-BGP. MP-BGP extended attributes In BGP-4, the attributes for IPv4 address format are NLRI, NEXT_HOP and AGGREGATOR (AGGREGATOR contains the IP address of the speaker generating the summary route). They are all carried in updates. To support multiple network layer protocols, BGP-4 puts information about network layer into NLRI and NEXT_HOP. MP-BGP introduces the following path attributes: • MP_REACH_NLRI —Multiprotocol Reachable NLRI, for advert ising feasible routes and next hops • MP_UNREACH_NLRI —Multiprotocol Unreachable NLRI, for withdrawing unfeasible routes These path attributes are both optional non-transitive, so BGP speakers not supporting multiprotocol ignore these attributes and do not forward them to its peers. Address family MP-BGP uses address families to differentiate networ k layer protocols. For address family values, see RFC 1700, Assigned Numbers . The system supports multiple MP-BGP extensions, including VPN extension, and IPv6 extension. Different extensions are co nfigured in respective address family view. NOTE: This chapter provides no detailed commands relate d to any specific extension application in MP-BGP address family view. Protocols and standards • RFC 1771, A Border Gateway Protocol 4 (BGP-4) • RFC 2858, Multiprotocol Extensions for BGP-4 • RFC 3392, Capabilities Advertisement with BGP-4 • RFC 2918, Route Refresh Capability for BGP- 4 • RFC 2439, BGP Route Flap Damping
201 • RFC 1997, BGP Communities Attribute • R F C 2796, BGP Route Reflection • RFC 3065, Autonomous System Confederations for BGP • RFC 4271, A Border Gateway Protocol 4 (BGP-4) • RFC 5291, Outbound Route Filtering Capability for BGP-4 • RFC 5292, Address-Prefix-Based Outbound Route Filter for BGP-4 • draft-ietf-idr-restart-08, Graceful Restart Mechanism for BGP BGP configuration task list Task Remarks Configuring BGP basic functions Creating a BGP connection Required. Specifying the source interface for TCP connections Optional. Allowing establishment of EBGP connection to an indirectly connected peer or peer group Optional. Controlling route generation Injecting a local network Required. Use at le ast one approach. Configuring BGP route redistribution Enabling default route redistribution into BGP Optional. Controlling route distribution and reception Configuring BGP route summarization Optional. Advertising a default route to a peer or peer group Configuring BGP route distribution/reception filtering policies Enabling BGP and IGP route synchronization Limiting prefixes received from a peer or peer group Configuring BGP route dampening Configuring a shortcut route Configuring BGP route attributes Specifying a preferred value for routes received Optional. Configuring preferences for BGP routes Optional. Configuring the default local preference Optional. Configuring the MED attribute Optional. Configuring the next hop attribute Optional. Configuring the AS-PATH attribute Optional. Tuning and optimizing BGP networks Configuring the BGP keepalive interval and holdtime Optional.