Before 1990, we felt that the traditional BGP technology was used very well, but then the Internet scale exploded, and some issues had to be considered. For example
, there are usually only a few interoperable PEERs, but the scale of the internal network continues to grow. How to make an iBGP mesh? I want to formulate and implement a new routing strategy, will it affect the existing network, will it cause routing flapping or even network disconnection? It is said that the network should be as simple as possible. How can the network be both stable and expanded at this time?
We have communicated and summarized with some institutions, and concluded that the following BGP technologies perform well in large networks: Route refresh; Cisco's peer-groups; Route Reflectors and Confederations. At the same time, it is recommended to deprecate: Soft Reconfiguration; Route Flap Damping.
1. Route Refresh:
Reset the BGP peer every time the BGP policy changes, because the router will not store the routes rejected by the current policy. However, if Hard BGP peer reset is used, BGP peering will be disconnected and CPU utilization will increase, affecting all network connections. Therefore, use Soft BGP peer reset, so that BGP peering will not be interrupted, only affecting the network involved in the policy change.
--BGP soft clear will not interrupt BGP connection; --No
additional configuration is required, peer auto-negotiation; --No
need to consume additional CPU;
--Require peer support "route refresh capability"-RFC2918
--cisco request peer to reconnect Send BGP routing commands:
clear ip bgp x.x.x.x [soft] in--cisco command to resend BGP routes to the peer:
clear ip bgp x.x.x.x [soft] out--Remember to add in / out
-Hard to clear BGP is the last resort, the effect is equivalent to router reboot Reboot
configuration example:
router bgp 100
address-family ipv4
neighbor 1.1.1.1 remote-as 101
neighbor 1.1.1.1 route-map infilter in neighbor 1.1.1.1 soft-reconfiguration inbound
! Outbound does not need to be configured !
clear ip bgp 1.1.1.1 soft in Second, Cisco's Peer Groups
Peer Groups solves these problems: -large
iBGP mesh configuration is cumbersome-
iBGP neighbors receive the same update
-router CPU wastes
applying peer-groups on double calculation , Group peers can be unified Outbound strategy, and send updates in groups.
The benefits brought by the actual operation are real. For example, the configuration is simpler, the probability of errors is reduced, and the readability of the configuration file is improved. The members of the peer can apply different inbound policies and even apply to eBGP neighbors. CPU utilization has also been reduced, helping us build iBGP mesh faster.
iBGP configuration example:
router bgp 100
address-family ipv4
neighbor ibgp-peer peer-group
neighbor ibgp-peer remote-as 100
neighbor ibgp-peer update-source loopback 0
neighbor ibgp-peer send-community
neighbor ibgp-peer route-map outfilter out
neighbor 10.0.0.1 peer-group ibgp-peer
neighbor 10.0.0.2 peer-group ibgp-peer
neighbor 10.0.0.2 route-map infilter in
neighbor 10.0.0.3 peer-group ibgp-peer
!Example of eBGP configuration:
router bgp 100
address-family ipv4
neighbor external-peer peer-group
neighbor external-peer send-community
neighbor external-peer route-map set-metric out
neighbor 160.89.1.2 remote-as 200
neighbor 160.89.1.2 peer-group external-peer
neighbor 160.89.1.4 remote-as 300
neighbor 160.89.1.4 peer-group external-peer
neighbor 160.89.1.6 remote-as 400
neighbor 160.89.1.6 peer-group external-peer
neighbor 160.89.1.6 filter-list infilter in
!Cisco is considering using update-groups instead of peer-group, (IOS internal coding has been reflected, but it can not be actually configured), please see the following has been displayed: "update-groups"
Router1#sh ip bgp 10.0.0.0/26
BGP routing table entry for 10.0.0.0/26, version 2
Paths: (1 available, best #1, table default)
Advertised to update-groups:
1
Refresh Epoch 1
Local
0.0.0.0 from 0.0.0.0 (10.0.15.241)
Origin IGP, metric 0, localpref 100, weight 32768, valid...As of now, peer groups are still regarded as "Best Practice" by many operators
Here are a few principles
for configuring peer-groups : 1. Always configure peer-groups for iBGP-
even if there are only a few iBGP peers
-easy to expand the network in the future
-improve the readability of configuration documents
2. Consider eBGP to configure peer-groups
-Particularly useful for configuring multiple BGP clients with the same AS number (RFC2270)-Used
at exchange points
-when the ISP policy of each peer is approximately the same-when
configuring the router server. For the router server, it is necessary to send all peers the same routing update
By the way, Juniper's BGP groups configuration
protocols {
bgp {
group ibgp {
type internal;
local-address 10.0.15.241;
family inet {
unicast;
}
export export-ibgp;
peer-as 10;
neighbor 10.0.15.242 {
description ”Router 2";
}
neighbor 10.0.15.243 {
description ”Router 3";
}
...etc...
}
}
}3. Route Reflectors for iBGP mesh to
solve the problem of 1 / 2n (n-1) iBGP mesh. A simple calculation shows that there will be 91 iBGP sessions in 14 routers full mesh, and there will be when n = 1000 Nearly 500,000 iBGP sessions.
You can use route reflector or federal Confederation
To be continued ... too late to continue writing tomorrow