Internet Routing Architectures (CISCO):Configurinbg Effective Internet Routing Policies Previous Table of Contents Next Controlling Route and Cache Invalidation A requirement of BGP is resetting the neighbors' TCP connection whenever a policy is changed for the new policy to take effect (clear ip bgp [* | address | peer-group] ). Clearing the sessions in this manner will restart the neighbor negotiations from scratch, invalidate the cache, and cause a major impact on the operation of live networks. Soft reconfiguration is a new approach that enables policies to be configured and activated without resetting the BGP TCP session. This enables new policies to take effect without significantly affecting the network. Soft configuration can be applied in two different ways, inbound and outbound. Use the following exec command: clear ip bgp [* | address | peer-group][soft [in|out]] Outbound Soft Reconfiguration Whenever outbound soft reconfiguration is applied, the new policies are automatically triggered, and appropriate updates are generated to enforce the new policy. Use the following exec command: clear ip bgp [* | address | peer-group] soft out Inbound Soft Reconfiguration Inbound soft reconfiguration is a bit more involved. All inbound updates (whether accepted or not accepted) need to be tracked by the router. Additional memory is required just to store this information. An additional router subcommand is needed to configure inbound soft reconfiguration: neighbor {address | peer-group} soft-reconfiguration inbound This command is required to start storing the received updates to do the soft reconfiguration. The exec command used to do the inbound reconfiguration is: clear ip bgp [* | address | peer-group] soft in To avoid the memory overhead needed for the inbound soft reconfiguration, the same outcome could be achieved by doing an outbound soft reconfiguration at the other end of the connection. If the "in/out" option is not specified (clear ip bgp [* | address | peer-group] soft), both inbound and outbound soft reconfiguration will be applied. The following example demonstrates the difference between clearing a BGP session between two routers without and with the soft configuration BGP feature. While the session is cleared, an output log will be displayed to show the actual session being established and the route updates being exchanged. Referring still to figure 11-14, RTA will be configured to send its updates to RTC with a metric of 5000. The following is RTA's configuration. Note the neighbor 172.16.20.1 soft-reconfiguration inbound command. This is needed only if clearing the session needs to take effect on the inbound; that is, in case we have no control over the neighbor router to clear the session on the outbound. RTA configuration: router bgp 65050 no synchronization bgp confederation identifier 3 network 172.16.220.0 mask 255.255.255.0 network 172.16.70.0 mask 255.255.255.0 neighbor 172.16.20.1 remote-as 1 neighbor 172.16.20.1 soft-reconfiguration inbound neighbor 172.16.20.1 filter-list 10 out neighbor 172.16.20.1 route-map setmetric out neighbor 172.16.70.2 remote-as 65050 no auto-summary ip as-path access-list 10 permit ^$ route-map setmetric permit 10 set metric 5000 For this information to take effect, the BGP session would have to be cleared between the two routers. Note how much overhead is caused by actually killing the TCP session between the two routers and starting over from scratch. The log will show that the BGP peer session is being first reset, then the neighbor election goes from Idle to Established, and then the actual routing updates will flow. RTA#clear ip bgp 172.16.20.1 BGP: 172.16.20.1 reset requested BGP: no valid path for 192.68.11.0/24 BGP: 172.16.20.1 reset by 0x27B740 BGP: 172.16.20.1 went from Established to Idle BGP: nettable_walker 192.68.11.0/255.255.255.0 no best path selected BGP: 172.16.20.1 went from Idle to Active BGP: 172.16.70.2 computing updates, neighbor version 21, table version 23, starting at 0.0.0.0 BGP: 172.16.70.2 send UPDATE 192.68.11.0/24 — unreachable BGP: 172.16.70.2 1 updates enqueued (average=27, maximum=27) BGP: 172.16.70.2 update run completed, ran for 0ms, neighbor version 21, start version 23, throttled to 23, check point net0.0.0.0 BGP: scanning routing tables BGP: 172.16.20.1 went from Active to OpenSent BGP: 172.16.20.1 went from OpenSent to OpenConfirm BGP: 172.16.20.1 went from OpenConfirm to Established BGP: 172.16.20.1 computing updates, neighbor version 0, table version 23, starting at 0.0.0.0 BGP: 172.16.20.1 send UPDATE 172.16.25.0/24, next 172.16.20.2, metric 5000, path 3 BGP: 172.16.20.1 send UPDATE 172.16.30.0/24, next 172.16.20.2, path (65060) BGP: 172.16.20.1 send UPDATE 172.16.50.0/24, next 172.16.20.2, metric 5000, path 3 BGP: 172.16.20.1 send UPDATE 172.16.60.0/24, next 172.16.20.2, path (65060) BGP: 172.16.20.1 send UPDATE 172.16.70.0/24, next 172.16.20.2, metric 5000, path 3 BGP: 172.16.20.1 send UPDATE 172.16.90.0/24, next 172.16.20.2, path (65060) BGP: 172.16.20.1 send UPDATE 172.16.65.0/26, next 172.16.20.2, path (65060) BGP: 172.16.20.1 send UPDATE 172.16.112.0/24, next 172.16.20.2, path BGP: 172.16.20.1 send UPDATE 172.16.220.0/24, next 172.16.20.2, path BGP: 172.16.20.1 send UPDATE 192.68.222.0/24, next 172.16.20.2, metric 5000, path 3 2 BGP: 172.16.20.1 4 updates enqueued (average=58, maximum=68) BGP: 172.16.20.1 update run completed, ran for 24ms, neighborversion 0, start version 23, throttled to 23, check point net 0.0.0.0 BGP: 172.16.20.1 rcv UPDATE about 192.68.11.0/24, next hop 172.16.20.1, path 1 metric 2000 BGP: 172.16.20.1 rcv UPDATE about 192.68.222.0/24, next hop 172.16.20.1, path 1 2 metric 2000 BGP: 172.16.20.1 rcv UPDATE about 172.16.25.0/24 — denied BGP: 172.16.20.1 rcv UPDATE about 172.16.30.0/24 — denied BGP: 172.16.20.1 rcv UPDATE about 172.16.50.0/24 — denied BGP: 172.16.20.1 rcv UPDATE about 172.16.60.0/24 — denied BGP: 172.16.20.1 rcv UPDATE about 172.16.70.0/24 — denied BGP: 172.16.20.1 rcv UPDATE about 172.16.90.0/24 — denied BGP: 172.16.20.1 rcv UPDATE about 172.16.65.0/26 — denied BGP: 172.16.20.1 rcv UPDATE about 172.16.112.0/24 — denied BGP: 172.16.20.1 rcv UPDATE about 172.16.220.0/24 — denied BGP: nettable_walker 192.68.11.0/255.255.255.0 calling revise_route BGP: revise route installing 192.68.11.0/255.255.255.0 -> 172.16.20.1 BGP: 172.16.70.2 computing updates, neighbor version 23, table version 24, starting at 0.0.0.0 BGP: NEXT_HOP part 1 net 192.68.11.0/24, neigh 172.16.70.2, next 172.16.20.1 BGP: 172.16.70.2 send UPDATE 192.68.11.0/24, next 172.16.20.1, metric 2000, path 1 BGP: 172.16.70.2 1 updates enqueued (average=59, maximum=59) BGP: 172.16.70.2 update run completed, ran for 4ms, neighbor version 23, start version 24, throttled to 24, check point net 0.0.0.0 BGP: 172.16.20.1 rcv UPDATE about 172.16.25.0/24 — withdrawn BGP: 172.16.20.1 rcv UPDATE about 172.16.30.0/24 — withdrawn BGP: 172.16.20.1 rcv UPDATE about 172.16.50.0/24 — withdrawn BGP: 172.16.20.1 rcv UPDATE about 172.16.60.0/24 — withdrawn BGP: 172.16.20.1 rcv UPDATE about 172.16.70.0/24 — withdrawn BGP: 172.16.20.1 rcv UPDATE about 172.16.90.0/24 — withdrawn BGP: 172.16.20.1 rcv UPDATE about 172.16.65.0/26 — withdrawn BGP: 172.16.20.1 rcv UPDATE about 172.16.112.0/24 — withdrawn BGP: 172.16.20.1 rcv UPDATE about 172.16.220.0/24 — withdrawn BGP: 172.16.20.1 computing updates, neighbor version 23, table version 24, starting at 0.0.0.0 BGP: 172.16.20.1 update run completed, ran for 0ms, neighbor version 23, start version 24, throttled to 24, check point net 0.0.0.0 BGP: scanning routing tables Previous Table of Contents Next