Case Study BGP Confederations

BGP confederations make large transit autonomous systems more manageable by enabling the administrator to break the AS into subautonomous systems. The subdivided AS itself becomes the confederation, and the subautonomous systems are the member autonomous systems. Autonomous systems outside of the confederation see the entire confederation as a single AS and do not see the member autonomous systems. Because the member autonomous systems are hidden from the outside, they may use either public or private AS numbers, although best practice suggests using private AS numbers.

The advantage of confederations is that they sharply reduce the number of IBGP peering sessions. IBGP is used normally within each member AS, but a special version of EBGP known as confederation EBGP is run between the autonomous systems. No IBGP sessions are configured from a BGP speaker in one AS to a BGP speaker in another AS within the confederation.

Figure 3-28 shows an example of a confederation. AS 1200 has been subdivided into three confederation autonomous systems: AS 65533, AS 65534, and AS 65535. From the perspective of outside autonomous systems, such as AS 1000 and AS 1500, the confederation is a single autonomous system: AS 1200. These external autonomous systems have no knowledge of the confederation member autonomous systems.

Figure 3-28 AS 1200 Is a BGP Confederation; Although It Consists of Several Subautonomous Systems, the Neighboring Autonomous Systems See the Confederation Only as AS 1200

Panorama Whitetooth

Figure 3-28 AS 1200 Is a BGP Confederation; Although It Consists of Several Subautonomous Systems, the Neighboring Autonomous Systems See the Confederation Only as AS 1200

Panorama Whitetooth

Talisman

AS 65534

AS 1500

AS 1200

AS 1000

Bridger

Lakeridge

AS 1200

Talisman

AS 65534

AS 1000

Bridger

AS 1500

Sugarloaf

Confederation EBGP is run between Panorama and Sunshine, between Sunshine and Talisman, and between Talisman and Whitetooth. Example 3-148 shows the configuration for Talisman.

Example 3-148 Configuring Talisman as a Confederation Router router ospf 65534 network 10.34.0.0 0.0.255.255 area 65534 network 10.255.0.0 0.0.255.255 area 0

i router bgp 65534 no synchronization bgp confederation identifier 1200 bgp confederation peers 65533 65535 neighbor Confed peer-group neighbor Confed ebgp-multihop 2 neighbor Confed update-source Loopback neighbor Confed next-hop-self neighbor MyGroup peer-group neighbor MyGroup remote-as 65534 neighbor MyGroup update-source Loopback0 neighbor 10.33.255.1 remote-as 65533 neighbor 10.33.255.1 peer-group Confed

I xnmple 3-148 Configuring Talisman as a Confederation Router (Continued)

neighbor 10.34.255.2 peer-group MyGroup neighbor 10.35.255.1 remote-as 65535 neighbor 10.35.255.1 peer-group Confed

Talisman is configured so that its local AS is 65534. Its peer connections to Whitetooth and Sunshine are set up like any other EBGP session, and the connection to Lakeridge is IBGP. The bgp confederation identifier command tells the router that it is a member of a confederation and the confederation ID. The bgp confederation peers command lists the member autonomous systems to which Talisman is connected. This command tells the BGP process that the EBGP connection is confederation EBGP rather than normal EBGP.

A confederation may run BGP only, a common IGP throughout the entire confederation, or different IGPs within each member AS. In Figure 3-28, all the routers within AS 1200 run OSPF. The OSPF permits local communication within the confederation and tells the BGP processes how to find their various neighbors. In the configuration in Example 3-148, no routes are redistributed between OSPF and BGP at any router. Subsequent configuration examples do not show the OSPF configuration.

Example 3-149 shows configurations of Lakeridge and Sugarloaf.

I «timple 3-149 Configuring EBGP Between Confederation Router Lakeridge and External Router Sugarloaf

Lakeridge router bgp 65534 no synchronization bgp confederation identifier 1200 neighbor 10.34.255.1 remote-as 65534 neighbor 10.34.255.1 update-source Loopback0 neighbor 10.34.255.1 next-hop-self neighbor 192.168.255.1 remote-as 1500 neighbor 192.168.255.1 ebgp-multihop 2 neighbor 192.168.255.1 update-source Loopback0

Sugarloaf router bgp 1500 network 192.168.1.0 network 192.168.2.0 neighbor 10,34.285.2 remote-as 1200 neighbor 10.34.255.2 ebgp-multihop 2 neighbor 10.34.255.2 update-source LoopbackO

At Lakeridge, the bgp confederation peers command is not used because Lakeridge is not running confederation EBGP. It does, however, have a normal EBGP connection to Sugarloaf. Notice that from the perspective of Sugarloaf, Lakeridge is in AS 1200, not AS 65534. Sugarloaf, being outside of the confederation, has no knowledge of the member autonomous systems.

Confederation EBGP is something of a hybrid between normal BGP and IBGP. Specifically, within a confederation, the following applies:

• The NEXT_HOP attribute of routes external to the confederation is preserved throughout the confederation.

• MULTI_EXIT_DISC attributes of routes advertised into a confederation are preserved throughout the confederation.

• LOCAL_PREF attributes of routes are preserved throughout the entire confederation not just within the member AS in which they are assigned.

• The AS numbers of the member autonomous systems are added to the AS_PATH within the confederation but are not advertised outside of the confederation. By default, the member AS numbers are listed in the AS_PATH as AS_PATH attribute type 4, AS_CONFED_SEQUENCE. If the aggregate-address command is used within the confederation, the as-set keyword causes member AS numbers behind tin aggregation point to be listed as AS JPATH attribute type 3, AS_CONFED_SET.

• The confederation AS numbers in an AS_PATH are used for loop avoidance but arc not considered when choosing a shortest AS_PATH within the confederation.

Most of these characteristics are due to the fact that from the outside, the confederation appears to be a single autonomous system. The following discussion provides examples <>l each of these characteristics.

In Figure 3-28, the routes in AS 1000 are advertised from Bridger to Nakiska with a NEXT_HOP attribute of 172.17.255.1. This attribute is preserved when the routes are advertised via IBGP from Nakiska to Sunshine. If Sunshine were connected to Talisman with a normal EBGP connection, Sunshine would change the NEXT_HOP of the routes t<» 10.33.255.1 before advertising them to Talisman. Because the connection is confederation EBGP, however, the original NEXT_HOP attribute is preserved. As a result, Lakeridge could have route entries for 172.17.0.0 and 172.18.0.0 with a next-hop address of 172.17.255.1. Lakeridge's connection to Sugarloaf is normal EBGP, so the routes are advertised to Sugarloaf with a NEXT_HOP attribute of 10.34.255.2.

The neighbor next-hop-self command is used throughout the confederation of Figure 3-2 s so that all next-hop addresses are known via the IGP. You can observe these commands in the configurations of Talisman and Lakeridge.

Bridger is configured to advertise its routes with a MED of 50, and Nakiska is configured to set the LOCAL_PREF of the same routes to 200. You can observe the results in Example 3-150. In a normal EBGP session, Sunshine would not advertise the MED that originated in AS 1000, or the LOCAL_PREF that should only have relevance within AS65533. Because the confederation is seen from the outside as a single AS, however, these values must be consistent throughout the confederation.

I Mi« in pie 3-150 The Routes from AS 1000 Have a MED of50andaWCAL_PREFof200atLakeridge; These Values Were Preserved Across the Confederation EBGP Connection from Sunshine

Lakeridge#show ip bgp

BGP table version is 28, local router ID is 10.34.255.2

Status codes: s

suppressed, * valid.

, > best, i - internal

Origin codes: i

- IGP, e - EGP, ? -

incomplete

Network

Next Hop

Metric LocPrf Weight

Path

*>i172.17.0.0

10.33.255.1

50 200 0

(65533)

1000 i

*>i172.18.0.0

10.33.255.1

50 200 0

(65533)

1000 i

*> 192.168.1.0

192.168.255.1

0 0

1500 i

*> 192.168.2.0

192.168.255.1

0 0

1500 i

Lakeridge#

You also can see in Example 3-150 that AS 65533 is included in the AS_PATH of the routes to the networks in AS 1000. The AS_CONFED_SEQUENCE is shown in parentheses for two reasons. First, it is not advertised outside of the confederation, as demonstrated in Example 3-151. Second, it is used only for loop avoidance within the confederation, not for path selection.

I »ijmple 3-151 Sugarloaf Sees the Confederation in Figure 3-28 as a Single Autonomous System and Does Not See the Member Autonomous Systems; the AS_CONFED_SEQUENCE, Shown in Parentheses in Example 3-150, Is Replaced with the Confederation ID 1200

Sugarloaf#show ip

bgp

BGP table version

is 32, local router ID is 192.168.255.1

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal

Origin codes: i -

IGP, e - EGP, ? - incomplete

Network

Next Hop Metric LocPrf Weight

Path

*> 172.17.0.0

10.34.255.2 0

1200 1000 i

*> 172.18.0.0

10.34.255.2 0

1200 1000 i

*> 192.168.1.0

0.0.0.0 0 32768

i

*> 192.168.2.0

0.0.0.0 0 32768

i

Sugarloaf#

In the BGP tables of Whitetooth and Panorama displayed in Example 3-152, you can observe a consequence of the fact that member AS numbers do not influence the path selection process. Both routers have two paths to each of the destinations in AS 1000 and AS 1500—one via its IBGP neighbor, and one via its confederation EBGP neighbor. Whitetooth, for instance, has two paths to network 172.17.0.0. The AS_PATH of one is (65534,65533,1000) and the other is (65533,1000). Clearly the latter AS_PATH is shorter, but the member AS numbers are ignored. As a result, the two paths are seen as equivalent: (1000). All else being equal, the BGP decision process chooses normal EBGP routes over confederation EBGP routes and confederation EBGP routes over IBGP routes. In Example 3-152, the choice is between a confederation EBGP route and an IBGP route.

Notice in the BGP tables of the two routers that the confederation EBGP path is chosen in every instance.

Example 3-152 The AS_CONFED_SEQUENCE, Shown in Parentheses in the Whitetooth and Panorama BGP Tables, Are Not Considered When Choosing a Shortest AS_PATH Within an AS Confederation

Whitetooth#show ip bgp

BGP table version is 9, local router ID is 10.35.255.1

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

Whitetooth#show ip bgp

BGP table version is 9, local router ID is 10.35.255.1

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

*> 172.

.17.0.0

10,

.34.

.255.

,1

50

200

0

(65534 65533) 1000

i

* i

10.

.33.

.255.

1

50

200

0

(65533) 1000 i

*> 172.

,18.0.0

10.

.34.

.255.

1

50

200

0

(65534 65533) 1000

i

* i

10,

.33,

.255.

,1

50

200

0

(65533) 1000 i

*> 192.

.168.1 .0

10,

.34,

.255.

,1

0

100

0

(65534) 1500 i

* i

10,

.33,

.255.

,1

0

100

0

(65533 65534) 1500

i

*> 192.

.168.2.0

10,

.34,

.255.

,1

0

100

0

(65534) 1500 i

* i

10,

.33,

.255.

,1

0

100

0

(65533 65534) 1500

Whitetooth#

Panorama#show ip bgp

BGP table version is 5, local router ID is 10.35.255.2

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete

Panorama#show ip bgp

BGP table version is 5, local router ID is 10.35.255.2

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete

Network

Next Hop

Metric

LocPrf Weight

Path

* i172.

,17.0.0

10,

.34.255.1

50

200

0

(65534 65533) 1000

*>

10,

.33.255.1

50

200

0

(65533) 1000 i

* i172.

,18.0.0

10,

.34.255.1

50

200

0

(65534 65533) 1000

*>

10,

.33.255.1

50

200

0

(65533) 1000 i

* i192.

,168.1 .0

10,

.34.255.1

0

100

0

(65534) 1500 i

*>

10,

.33.255.1

0

100

0

(65533 65534) 1500

* i192.

,168.2.0

10,

.34.255.1

0

100

0

(65534) 1500 i

*>

10,

.33.255.1

0

100

0

(65533 65534) 1500

Panorama#

Panorama#

In the topology of Figure 3-28, ignoring the member AS numbers presents no problem. Consider the topology in Figure 3-29, however, where everything is identical except the BGP router IDs in AS 65534 and AS 65535, which have been swapped. This change might seem innocent enough, but consider the effect that it has on the BGP decision process at Sunshine. The routes to the networks in AS 1500 are being advertised by both Talisman and Panorama. The AS_PATH lengths are the same because the member AS numbers are ignored, and both neighbors are confederation EBGP peers. Both Talisman and Panorama use the neighbor next-hop-self command, so the IGP path to the next-hop address of both routes is the same. The tiebreaker becomes the lowest neighboring router ID, which is Panorama. Sunshine therefore chooses the path through AS 65535 via Panorama rather than the more-direct path via Talisman, as demonstrated in Example 3-153.

t lyure 3-29 The Router IDs of the Routers in AS 65534 and AS 65535 Have Been Swapped t lyure 3-29 The Router IDs of the Routers in AS 65534 and AS 65535 Have Been Swapped

I" «ample 3-153 Sunshine Has Chosen Suboptimal Paths to the Networks in AS 1500 Based on Panorama s Lower Router ID

Sunshine#show ip bgp

BGP table version is 17, local router

ID is 10.33.255.1

Status codes: s

suppressed, d damped,

h history, * valid,

> best, i - internal

Origin codes: i

- IGP, e - EGP, ? - incomplete

Network

Next Hop

Metric LocPrf Weight Path

*>i172.17.0.0

10.33.255.2

50 200

0 1000 i

*>i172.18.0.0

10.33.255.2

50 200

0 1000 i

*> 192,168,1,0 10.34»255,2

0 100

0 (65535 65534) 1500 i

*

10.35.255.1

0 100

0 (65534) 1500 i

*» 192.198.2.0

10.34.255.2

0 100

0 (65535 65534) 1500 i

*

10.35.255.1

0 100

0 (65534) 1500 i

Sunshine#

Little can be done to remedy the problems in the topology of Figure 3-29. Attempting to filter routes or manipulate administrative weights will make the configurations highly complex, defeating one of the reasons for creating a confederation in the first place. Attempting to manipulate the route choices with LOCAL_PREF or MED attributes is fraught with hazards, because the attributes are advertised throughout the confederation; with the loops in the topology, the attributes can affect route choices in unintended locations.

You must design confederations so that problems such as those presented by the topology in Figure 3-29 do not arise. A common design technique takes its cue from OSPF, in which all areas must interconnect through a single backbone area, eliminating the possibility of inter-area loops.

Figure 3-30 shows the same routers as in the earlier illustrations, but the member autonomous systems have been redesigned. AS 65000 is a backbone autonomous system, and all the other autonomous systems must interconnect through it. The result is that the path from any nonbackbone AS to any other nonbackbone AS is the same distance. The connections between AS 65000 and AS 65535 demonstrate that it is still possible to have redundant connections, but not between nonbackbone autonomous systems. BGP's loop avoidance mechanism prevents the possibility of suboptimal inter-AS paths.

Figure 3-30 AS 65000 Is a Backbone AS in the Confederation; All Other Areas Interconnect Through It, Making the ASJPATHs Between All Nonbackbone Autonomous Systems the Same Length

Figure 3-30 AS 65000 Is a Backbone AS in the Confederation; All Other Areas Interconnect Through It, Making the ASJPATHs Between All Nonbackbone Autonomous Systems the Same Length

Another advantage of a loop-free topology such as the one in Figure 3-30 is that the MEI ) attribute can be used between member autonomous systems. To understand why MEDs are-safe in this topology, look first at the topology in Figure 3-31. This is similar to the confederation in Figure 3-28, except that AS 65534 has redundant connections to AS 65535. Suppose MEDs are used so that AS 65535 prefers the Whitetooth/Lakeridge link over the Panorama/Talisman link for traffic destined for AS 1500. Correct results can be achieved between these two autonomous systems, but the problem is that the MEDs are als< >

forwarded from AS 65534 to AS 65533. Depending on how the latter AS is configured to handle MEDs, and which MEDs are sent by Talisman, AS 65533 could again choose a suboptimal route.

f Iqure 3-31 MED Attributes Are Forwarded Throughout a Confederation; if AS 65534 Uses MEDs to Influence the Preferences of AS 65535, AS 65533 Will Also Receive the MEDs f Iqure 3-31 MED Attributes Are Forwarded Throughout a Confederation; if AS 65534 Uses MEDs to Influence the Preferences of AS 65535, AS 65533 Will Also Receive the MEDs

In Figure 3-30, AS 65000 can safely send MEDs to AS 65535. The only path AS 65535 has to other nonbackbone autonomous systems is through the backbone. A route that includes 65000 in its AS_PATH is not accepted by Sunshine or Talisman, so MEDs sent from those routers to AS 65535 are not seen by other member autonomous systems.

By default, Panorama and Whitetooth in Figure 3-30 prefer confederation EBGP routes over IBGP routes. So Panorama sends all traffic destined for the networks in AS 1000 and AS 1500 to Sunshine; Whitetooth sends all traffic for the same destinations to Talisman. MEDs can be used so that AS 65535 sends all traffic destined for the networks in AS 1000 across the Panorama/Sunshine link and all traffic destined for the networks in AS 1500 across the Whitetooth/Talisman link. Example 3-154 shows the configurations of Sunshine and Talisman.

Example 3-154 Configuring Sunshine and Talisman to Send MEDs to AS 65535

Sunshine router bgp 65000 no synchronization bgp confederation identifier 1200 bgp confederation peers 65533 65535 neighbor 10.33.255.2 remote-as 65533 neighbor 10.33.255.2 ebgp-multihop 2 neighbor 10.33.255.2 update-source Loopback0 neighbor 10.34.255.2 update-source Loopback0 neighbor 10.34.255.2 ebgp-multihop 2 neighbor 10.34.255.2 update-source Loopback0 neighbor 10.34.255.2 next-hop-self neighbor 10.34.255.2 route-map SETMED out neighbor 10.35.255.1 remote-as 65000 neighbor 10.35.255.1 update-source Loopback0

i ip as-path access-list 1 permit _1000_

ip as-path access-list 2 permit _1500_

j route-map SETMED permit 10 match as-path 1 set metric 100

i route-map SETMED permit 20 match as-path 2 set metric 200

j route-map SETMED permit 30

Talisman router bgp 65000 no synchronization bgp confederation identifier 1200 bgp confederation peers 65534 65535 neighbor 10.33.255.1 remote-as 65000 neighbor 10.34.255.1 remote-as 65535 neighbor 10.34.255.1 ebgp-multihop 2 neighbor 10.34.255.1 update-source LoopbackO neighbor 10.34.255.1 next-hop-self neighbor 10.34.255.1 route-map SETMED out neighbor 10.35.255.2 remote-as 65534 neighbor 10.35.255.2 ebgp-multihop 2 neighbor 10.35.255.2 update-source Loopback0

i ip as-path access-list 1 permit _1500_ ip as-path access-list 2 permit _1000_ i route-map SETMED permit 10 match as-path 1 set metric 100

I xiimple 3-154 Configuring Sunshine and Talisman to Send MEDs to AS 65535 (Continued)

route-map SETMED permit 20 match as-path 2 set metric 200

i route-map SETMED permit 30

Sunshine sets to 100 the MED for all routes whose AS_PATH includes 1000; the MED for all routes whose AS_PATH includes 1500 is set to 200. Talisman does just the opposite. Example 3-155 shows before-and-after views of Panorama's BGP table. In the first table, the router prefers the confederation EBGP paths for all destinations. In the second table, the MEDs have been changed so that Panorama sends traffic destined for the networks of AS 1500 across the IBGP link to Whitetooth, which forwards the traffic across its preferred confederation EBGP link.

t Knmple 3-155 Panorama's BGP Table, Before and After the Routers in AS 65000 Are Configured to Send MED Attributes

Panorama#show ip bgp

BGP table version is 34, local router

ID is 10.

35.

2.1

Status

codes: s

suppressed, d damped,

h history, *

valid,

> best, i

- internal

Origin

codes: i

- IGP, e - EGP, ? - incomplete

Network

Next Hop

Metric

LocPrf Weight

Path

* i172,

.17.0.0

10.35.255.1

0

100

0

(65000

65533)

1000

i

*>

10.33.255.1

0

100

0

(65000

65533)

1000

i

* i172,

.18.0.0

10.35.255.1

0

100

0

(65000

65533)

1000

i

*>

10.33.255.1

0

100

0

(65000

65533)

1000

i

* i192,

.168.1.0

10.35.255.1

0

100

0

(65000

65534)

1500

i

*>

10.33.255.1

0

100

0

(65000

65534)

1500

i

* i192.

.168.2.0

10.35.255.1

0

100

0

(65000

65534)

1500

i

*>

10.33.255.1

0

100

0

(65000

65534)

1500

i

Panorama#

Panorama#show ip bgp

BGP table version is 47, local router

ID is 10.

35.

2.1

Status

codes: s

suppressed, d damped,

h history, *

valid,

> best, i

- internal

Origin

codes: i

- IGP, e - EGP, ? - incomplete

Network

Next Hop

Metric

LocPrf Weight

Path

* i172.

.17.0.0

10.35.255.1

200

100

0

(65000

65533)

1000

i

*>

10.33.255.1

200

100

0

(65000

65533)

1000

i

* i172.

,18.0.0

10.35.255.1

200

100

0

(65000

65533)

1000

i

*>

10.33.255.1

200

100

0

(65000

65533)

1000

i

*>i192.

,168.1.0

10.35.255.1

100

100

0

(65000

65534)

1500

i

*

10.33.255.1

200

100

0

(65000

65534)

1500

i

*>i192.

,168.2.0

10.35.255.1

100

100

0

(65000

65534)

1500

i

*

10.33.255.1

200

100

0

(65000

65534)

1500

i

Panorama#

In Figure 3-32, two subnets local to the confederation are added: 10.33.5.0/24 in AS 65533 and 10.35.5.0/24 in AS 65535. Sunshine and Talisman are reconfigured to apply the same routing policies to these two subnets as are applied to the external networks. That is, MEDs are set so that AS 65535 sends traffic destined for 10.33.5.0/24 across the Panorama/Sunshine link and traffic destined for 10.35.5.0/24 across the Whitetooth/Talisman link.

Figure 3-32 Local Subnets Are Added to AS 65533 and AS 65535

Panorama Whitetooth

Nakiska

AS 65533

Panorama Whitetooth

AS 65535

s

sj

s

AS 65000

Talisman

Sunshine

Talisman

Lakeridge

AS 65534

AS 1200

AS 1000

Bridger

AS 1500

Sugarloaf

You can see in Panorama's BGP table in Example 3-156 that the policies are not having the desired effect. The MEDs are correctly configured, but the router is still preferring its confederation EBGP path for both subnets rather than preferring the IBGP path, with its lower MED, for traffic to 10.35.5.0/24. The reason for this behavior is that by default, the MED of a confederation-interior route (signified by the absence of any exterior AS numbers in the AS_PATH) is not considered in the BGP decision process.

Example 3-156 Panorama Is Choosing Paths to Confederation-Exterior Destinations Based on the Lowest MED, But the MED Is Not Considered When Choosing Confederation-Interior Paths

Panorama#show ip bgp

BGP table version is 127, local router ID is 10.35.2.1

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete

* »muple 3-156 Panorama Is Choosing Paths to Confederation-Exterior Destinations Based on the Lowest MED, But the MED Is Not Considered When Choosing Confederation-Interior Paths (Continued)

Network

Next Hop

Metric

LocPrf Weight

Path

* i10.33.5.0/24

10

.35.255.1

200

100

0

(65000 65533)

i

*>

10,

.33.255.1

100

100

0

(65000 65533)

i

*> 10.35.5.0/24

10,

.33.255.1

200

100

0

(65000 65534)

i

* i

10,

.35.255.1

100

100

0

(65000 65534)

i

*> 172.17.0.0

10,

.33.255.1

100

100

0

(65000 65533)

1000

i

*> 172.18.0.0

10,

.33.255.1

100

100

0

(65000 65533)

1000

i

*>i192.168.1.0

10,

.35.255.1

100

100

0

(65000 65534)

1500

i

*

10,

.33.255.1

200

100

0

(65000 65534)

1500

i

*>i192.168.2.0

10,

.35.255.1

100

100

0

(65000 65534)

1500

i

*

10,

.33.255.1

200

100

0

(65000 65534)

1500

Panorama#

The command bgp deterministic-med tells the BGP process to compare MEDs when choosing paths to confederation-interior destinations. Example 3-157 shows the configuration for Panorama using the bgp deterministic-med command.

I" ■Minpie 3-157 Configuring Panorama to Compare MEDs When Choosing Paths to Confederation-Interior Destinations router bgp 65535 no synchronization bgp confederation identifier 1200 bgp confederation peers 65000 bgp deterministic-med neighbor 10.33.255.1 remote-as 65000 neighbor 10.33.255.1 ebgp-multihop 2 neighbor 10.33.255.1 update-source Loopback0 neighbor 10.34.255.1 remote-as 65535 neighbor 10.34.255.1 update-source Loopback0

Example 3-158 shows the results of configuring Panorama with the bgp deterministic-med command. Panorama now uses the path with the lowest MED, whether the path is interior or exterior to the member AS. You can obtain similar results by using the bgp always-compare-med command, discussed in an earlier case study. The difference is that this command, unlike bgp deterministic-med, compares the MEDs of paths to the same destination regardless of whether the MEDs are advertised from the same AS. In a backbone-based confederation such as the one in Figure 3-32, this is not an issue, because no AS has a path to more than one neighboring AS.

Example 3-158 Panorama Is Considering the MED When Choosing Both Confederation-Interior and Confederation-Exterior Routes

Panorama#show ip bgp

BGP table version is 10, local router ID is 10.35.2.1

Panorama#show ip bgp

BGP table version is 10, local router ID is 10.35.2.1

Status codes: s

suppressed, d damped, h history,

* valid,

> best, i

- internal

Origin codes: i

- IGP,

e

- EGP, ? ■

■ incomplete

Network

Next Hop

Metric LocPrf Weight

Path

*> 10.33.5.0/24

10.

.33,

.255.1

100

100

0

(65000

65533)

i

* i

10,

.35,

.255.1

200

100

0

(65000

65533)

i

*>i10.35.5.0/24

10,

.35,

.255.1

100

100

0

(65000

65534)

i

*

10,

.33,

.255.1

200

100

0

(65000

65534)

i

*> 172.17.0.0

10,

.33,

.255.1

100

100

0

(65000

65533)

1000

i

*> 172.18.0.0

10,

.33.

.255.1

100

100

0

(65000

65533)

1000

i

*>i192.168.1.0

10,

.35,

.255.1

100

100

0

(65000

65534)

1500

i

*

10,

.33,

.255.1

200

100

0

(65000

65534)

1500

i

*>i192.168.2.0

10,

.35,

.255.1

100

100

0

(65000

65534)

1500

i

*

10,

.33,

.255.1

200

100

0

(65000

65534)

1500

i

Panorama#

You can use yet another command to accomplish the same goals: bgp bestpath med confed. This command has the same effect as bgp deterministic-med, with one difference. If a route has an external AS number in its AS_PATH, and other routes to the same destination have only confederation AS numbers in their AS_PATHs, the router picks the confederation-internal path with the lowest MED and ignores the path with the external AS number. However, such a situation should be very rare. The existence of two routes to the same destination, one indicating that the destination is inside the confederation and another that the destination is outside, is probably evidence of a misconfiguration or a poor design.

Was this article helpful?

0 0
100 SEO Tips

100 SEO Tips

100 SEO Tips EVERY SEO Enthusiast Should Know. This Report 100 SEO Tips will help you to Utilize These Tips to Dominate The Search Engine Today.

Get My Free Ebook


Post a comment