Using BGP in the Enterprise Network The Internet : a collection of autonomous systems. BGP : provides the routing between autonomous systems. If an organization has only one connection to one ISP, would use a default route. if have multiple connections to one or to multiple ISPs, BGP may be appropriate because it allows them to manipulate path attributes to select the optimal path. External BGP (EBGP) : between routers in different AS. Internal BGP (IBGP) : between routers in the same AS.
BGP Multihoming Options Multihoming : An autonomous system has more than one connection to the Internet. Why multihoming? To increase the reliability of the connection to the Internet: If one connection fails, the other connection remains available. To increase the performance of the connection: Better paths can be used to certain destinations. Three common ways to do multihoming: Each ISP passes only a default route to the autonomous system: Each ISP passes only a default route and provider-owned specific routes to the autonomous system Each ISP passes all routes to the autonomous system.
Option 1: Default Routes from All Providers limitations of this option: Path manipulation cannot be performed because only a single route is being received from each ISP. Bandwidth manipulation is extremely difficult and can be accomplished only by manipulating the IGP metric of the default route. Diverting some of the traffic from one exit point to another is challenging because all destinations are using the same default route for path selection.
Option 2: Default Routes and Partial Updates The enterprise (AS 64500) asked both providers to also send routes to networks in AS 64520. The routes to other AS are decided by the IGP metric that is used to reach the default route within the autonomous system.
Option 3: Full Routes from All Providers Allows the internal routers of the autonomous system to take the path through the best ISP for each route
Autonomous System Numbers ; 16-bits, ranging from 1 to 65535 64512 ~ 65535 : private use BGP : does not look at speed for the best path. Rather, BGP is a policy-based routing (PBR) protocol that allows an autonomous system to control traffic flow using multiple BGP path attributes.
Path-Vector Functionality BGP routers : exchange network reachability information, path vectors, made up of path attributes. Path-vector information : a list of the full path of BGP autonomous system numbers (hop by hop) to reach a destination network and the networks that are reachable at the end of the path.
Path-Vector Functionality The collection of path information is expressed as a sequence of autonomous system numbers called the AS path. This sequence forms a route to reach a specific destination.
BGP Routing Policies BGP is highly applicable as an inter-autonomous-system routing protocol (EX) All possible paths for AS 64512 to reach networks in AS 64700 through AS 64520: 64520 64600 64700 64520 64600 64540 64550 64700 64520 64540 64600 64700 64520 64540 64550 64700 AS 64520 advertises to AS 64512 only its best path, 64520 64600 64700. To reach the networks in AS 64700, AS 64512 can choose to use AS 64520 or AS 64530
Establishing a Connection Between External BGP Neighbors
Establishing a Connection Between Internal BGP Neighbors each router within the autonomous system learns about paths to the external networks via IBGP. The IBGP neighbor can be reached by a directly connected network, static routes, or by the internal routing protocol.
When an IBGP router receives an update about a destination from an IBGP peer, it tries to verify reachability to that destination via an IGP, such as RIP or OSPF. If the IBGP router can’t find the destination network in it’s IGP routing table, it will not advertise the destination to other BGP peers. AS Synchronization (Rick)
The BGP synchronization rule states that a BGP router (RTC) should not advertise to external neighbors (ISP2) destinations (188.8.131.52/24) learned from inside BGP neighbors (RTA) unless those destinations are also known via an IGP (RTD and RTB). If a router knows about these destinations via an IGP, it assumes that the route has already been propagated inside the AS, and internal reachability is guaranteed. AS Synchronization ( Rick)
If the IBGP router (RTC) does have an IGP route to this destination, the route is considered synchronized, and the router will announce it to other BGP peers (ISP2). Otherwise, the router will treat the route as not being synchronized with the IGP and will not advertise it. AS Synchronization (Rick)
The Cisco IOS offers an optional command called no synchronization. This command enables BGP to override the synchronization requirement, allowing the router to advertise routes learned via IBGP irrespective of an existence of an IGP route. AS Synchronization (Rick)
In practice, two situations exist where synchronization can be safely turned off on border routers: When all transit routers inside the AS are running fully meshed IBGP. Internal reachability is guaranteed because a route that is learned via EBGP on any of the border routers will automatically be passed on via IBGP to all other transit routers. When the AS is not a transit AS. AS Synchronization (Rick)
Synchronization Within an Transit Autonomous System Transit AS : 외부 AS 간의 트래픽을 라우팅, 전형적 : ISPs. Redistributing BGP into OSPF in not recommended run IBGP on all routers within the AS.
IBGP in a Nontransit Autonomous System Nontransit AS : Multihomed AS with two ISPs Does not pass routes between the ISPs. 하지만 AS 내부의 BGP routers 은 그 AS 에 전달된 모든 BGP routes 을 알아야 한다. ( 왜 ?) 적절한 라우팅 결정을 위하여. 주로 BGP routers 는 Border Router. AS 에서 routing loops 을 피하기 위하여, IBGP 를 통하여 배운 routes 는 다른 동료 IBGP 에게 전달하지 않는다. 따라서 must use fully meshed BGP
Routing Issues in a Transit Autonomous System Router D 와 C 가 BGP 를 돌리지 않으면 B 와 E 가 peer 관계를 맺더라도 AS 65103 에서 AS 65101 로 가는 패킷이 전달될 수 없다. Transit AS 는 IBGP 가 fully mesh 여야 한다.
IBGP Peering Issue 시나리오 1) D: neighbor 10.3.3.1 remote-as 65102. 2) but A send BGP packets to D via B. 3) the source IP address: 10.1.1.1. 4) D : peer ip not match, BGP drop packet. Solution : use loop back!!
BGP neighbor update-source Command 물리적 인터페이스 대신 loopback 인터페이스를 사용하면 BGP 패킷 소스 ip 주소도 loopback ip 주소로 하여야 한다. Use : update-source option BGP 는 IP 프로토콜 상에서 실행된다. BGP 프로토콜은 IP 패킷 근원지, 목적지 IP 주소가 필요 근원지 주소는 디폴트로 출구 인터페이스 주소가 사용된다.
BGP neighbor update-source Command 만약 BGP 이웃을 Lo 로 잡고 update source 를 Lo 로 하지 않으면 BGP 패킷의 소스 IP 는 인터페이스 IP 가 들어간다. BGP 패킷 drop !!!
EBGP Peering Issue EBGP peers : 보통 직접 연결되어야 한다. (usually only one hop away). neighbor ebgp-multihop command : - 다중 홉 거리에 떨여져 있어도 이웃관계 유지. - Loop back 주소를 사용하는 경우에 유리.
EBGP Peering Issue AS 간에는 IGP 가 사용되지 않기 때문에, 도움없이는 이웃 라우터의 loopback 에 도달할 수 없다. 각 라우터는 상대 라우터에 도달할 수 있는 경로를 설정하기 위하여 각각 static routes 를 설정한다.
Next Hop Behavior 라우터 C 는 10.10.10.3 를 찾기 위하여 자신의 IGP 라우팅 테이블을 거듭 조회 (recursive lookup) 한다.
BGP neighbor next-hop-self Command 해당 이웃에 대하여 모든 BGP 업데이트의 next hop 주소를 자신의 인터페이스 주소로 설정하도록 함.
Injection Routing Information into BGP neighbor command : tells BGP where to advertise, network command : tells BGP what to advertise
BGP network Command Example 192.168.1.0/24 or 192.168.1.1/32 doses not match The BGP auto-summary : 재분배되는 모든 서브넷은 BGP 테이블에서 classful boundaries 로 요약된다. 12.2(8)T 이후 : default off.
BGP Synchronization Example A, B, C, D : running IBGP & IGP with each other. A, B, C, D : have IGP routes to the internal networks of AS 65500, but do not have routes to external networks such as 172.16.0.0. Because A and B : not redistributing the BGP routes into the IGP.
6.4 Advanced BGP Configuration and Verification
BGP FSM includes six states: 1. Idle 2. Connect 3. Active 4. OpenSent 5. Open Confirm 6. Established Note: These arrows should show pointing back to the same state. BGP FSM (Rick)
BGP always begins in the Idle state, in which it refuses all incoming connections. It is normally initiated by an administrator or a network event. When Start event occurs, the BGP process: Initializes all BGP resources Starts the ConnectRetry timer Initializes a TCP connection the the neighbor Listens for a TCP initialization from the neighbor Changes its state to Connect (found ip addr to neighbor & received SYNC ACK) Idle State
Connect State In this state, the BGP process is waiting for the TCP connection to be completed. If the TCP connection is successful, the BGP process: Clears the ConnectRetry timer Completes initialization Sends an Open message to the neighbor Transitions to the OpenSent state
Connect State If the TCP connection is unsuccessful, the BGP process: Continues to listen for a connection to be initiated by the neighbor Resets the ConnectRetry timer Transitions to the Active state
Active State In this state, the BGP process is trying to initiate a TCP connection with the neighbor. If the TCP connection is successful: Clears the ConnectRetry timer Completes initialization Sends an Open message to the neighbor Transitions to the OpenSent state
Active State If the ConnectRetry timer expires while BGP is in the Active State, the BGP process: Transitions back to the Connect state Resets the ConnectRetry timer In general, a neighbor state that is switching between "Connect" and "Active" is an indication that something is wrong and that there are problems with the TCP connection. It could be because of many TCP retransmissions, or the incapability of a neighbor to reach the IP address of its peer.
OpenSent State In this state an Open message has been sent and BGP is waiting to hear an Open message from its neighbor. When an Open message is received, all its fields are checked. If errors exist, a Notification message is sent and the state transitions to Idle. If no errors exist, a Keepalive message is sent and the Keepalive timer is set, the peer is determined to be internal or external, and state is changed to OpenConfirm. errors No errors
OpenConfirm State In this state, the BGP process waits for a Keepalive or Notification message. If a Keepalive message is received, the state transitions to Established. If a Notification message is received, or a TCP disconnect is received, the state transitions to Idle. error No errors
Established State In this state, the BGP connection is fully established and the peers can exchange Update, Keepalive and Notification messages. If an Update or Keepalive message is received, the Hold timer is restarted. If a Notification message is received, the state transitions to Idle.
Configuring a Peer Group More efficient because updates are generated only once per peer group rather than repetitiously for each neighboring router. The generated update is replicated for each neighbor that is part of the internal peer group. Save processing time in generating the updates for all IBGP neighbors. Make the router configuration easier to read and manage to link the address of a neighboring router to a specific peer group name.
Configuring a Peer Group Example If C is not using a peer group and receives a change from AS 65101, it must generate an individual update for each IBGP neighbor and run each update against distribute list 20. If C is using a peer group, it creates a single update and processes it through distribute list 20 once. The update is replicated for each neighbor that is part of the internal peer group.
Soft Reset of BGP Sessions (in Bound) 2 ways to perform an inbound soft reconfiguration: Using stored routing update information Dynamically allows the dynamic exchange of route refresh requests and routing information between BGP routers debug ip bgp updates