| Previous | Table of Contents | Next |
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 |