BGP Part-1 - Cloud Object Storage | Store & Retrieve Data ... Part-1 Prerequisite knowledge required:\爀圀栀愀琀椀猀愀渀䄀甀琀漀渀漀洀漀甀猀匀礀猀琀攀洀

$Page 1: BGP Part-1 - Cloud Object Storage | Store & Retrieve Data ... Part-1 Prerequisite knowledge required:\爀圀栀愀琀椀猀愀渀䄀甀琀漀渀漀洀漀甀猀匀礀猀琀攀洀$
BGP Part-1

www.ine.com

Presenter

Presentation Notes

Prerequisite knowledge required: ---What is an Autonomous System and where would you go to get one for your company? ---IGP routing ---IP Addressing, subnetting, and summarization theory

Copyright © www.ine.com

Comparison between IGPs & BGP

» Similarit ies and differences between BGP and IGPs (OSPF and EIGRP): • BGP needs to form neighborship like IGPs.

• BGP needs to advertise prefixes, just like IGPs.

• BGP also advertises Next Hops for those prefixes.

• Neighbor IP address may not be on a common subnet for BGP.

• BGP uses TCP (179) and unicast…IGPs do not.

Presenter

Presentation Notes

So at a high level lets look at the similarities and differences between BGP and the IGPs. BGP is going to form a neighbor relationship to exchange routing information just like EIGRP, and just like OSPF. The primary difference in how we peer is that our neighbor is that the IP addresses don’t have to be on the same subnet. We can peer over multiple devices. And this peering relationship actually uses TCP to build the adjacency. IGPs have their own IP protocol they use and manage their neighbors that way. With BGP we use the layer 4 protocol to handle the validity of data, and acknowledge that our peer received what we sent. And BGP will advertise prefixes to it’s peers just like an IGP. The main difference in that information sent in BGP advertisements not only includes prefix/mask/next-hop information…but a lot of other descriptive information as well.


» Neighbors versus Peers • IGP routers are called “neighbors” which typically denotes a direct-

connection.

• BGP routers are called “peers” because there is no need for direct-connection.

» Routes versus NLRI • IGP protocols exchange unicast routes

• BGP also exchanges unicast routes, but can also exchange other types of information.

• For this reason we say BGP exchanges NLRI (Network-Layer Reachability Information)

Comparison between IGPs & BGP

Overview of iBGP and eBGP

www.ine.com


Overview of iBGP and eBGP

» There are two types of neighbors in BGP: internal BGP (iBGP) and external BGP (eBGP).

» A BGP router behaves different ly in several ways depending on whether the peer (neighbor) is an iBGP or eBGP peer.

Router BGP 1 neighbor 2.2.2.2 remote-as 2

Router BGP 1 neighbor 2.2.2.2 remote-as 1

eBGP Peering

iBGP Peering

Presenter

Presentation Notes

There are BGP’s different neighbor types: There are 2, one is the internal BGP neighbor, or the external BGP neighbor To be an IBGP neighbor is simple, be in the same AS as your peer. When you’re in a different AS than your peer, then its an external bgp neighbor relationship And the reason we’re bringing this up now is because BGP handles those peering relationships differently in multiple ways


iBGP and eBGP Differences (Overview)

» Peer establishment • eBGP imposes certain rules/restrictions not imposed by iBGP

» Prefix exchange • BGP updates received from external peers can be forwarded on to

any other type of peer.

• BGP updates received from internal peers can ONLY be forwarded on to external peers.

» Update modificat ion • Certain BGP Path Attributes may only be forwarded to external…or

internal peers.

Presenter

Presentation Notes

When it comes to Administrative Distance, eBGP has a lower value than iBGP but unlike IGP routing protocols, iBGP routes can still be preferred over eBGP routes under certain conditions. - eBGP = Admin Distance 20 iBGP = Admin Distance 200

BGP Neighborship Requirements

www.ine.com


BGP Peering Overview

1 2 1.1.1.1 1.1.1.2

AS# 1 AS# 2

1 Ensure BGP peers have IP reachability to each other.

2 Configure basic eBGP on each router.

3 TCP 3-Way Handshake must complete 4 BGP Peering must complete

5 BGP Update Exchange 6 BGP Bestpath Selection Process

router bgp 1 neighbor 1.1.1.2 remote-as 2


TCP Sync (179) TCP Sync + Ack (179)

TCP ACK (179)

BGP Peering Establishment

BGP Update Exchange

These are the best paths I’ve seen so far!

I’ve got better paths for these same prefixes!!

Presenter

Presentation Notes

This is an example of an eBGP peering…however the exact same steps must take place for an iBGP peering. - eBGP assumes that peers are directly connected. This can be circumvented via configuration. iBGP doesn’t care if peers are directly-connected or not.


eBGP Neighborship Overview

» To configure BGP Peers, use the following commands: • router bgp asn (global command)

• neighbor ip-address remote-as remote-asn (BGP subcommand)

» The asn in the router bgp command is the local AS number of the router.

Presenter

Presentation Notes

A router can only be in ONE BGP Autonomous System. It’s not like EIGRP or OSPF that allow you to configure multiple processes of the same routing protocol. To configure an external BGP neighbor, we first must enable the BGP process, just like OSPF and EIGRP. Then, we use the neighbor statement to define the IP address our TCP session is destined for, and the Autonomous system that that IP address lives in. And the ASN that we use in the router BGP command is the value of OUR AS.


BGP Peering Sanity Checks

1 2 1.1.1.1 1.1.1.2

AS# 1 AS# 2

1 Source IP address of incoming TCP connection must be from an expected/configured BGP peer.

2 Peer’s advertisement of his BGP AS# must be what we expect.

3 If BGP authentication is used, same password must be configured.

4 Peers must have unique BGP Router-IDs

5 Peers must use the same BGP version.




TCP ACK (179)

BGP Peering Establishment

Presenter

Presentation Notes

Like IGP protocols that build neighbor relationships, there are certain “sanity checks” that must match before two routers will become iBGP or eBGP peers. - These exact same sanity checks exist whether the two peers are eBGP or iBGP peers.


BGP Router-ID

» Just like any IGP, BGP elects a Router-ID. » The BGP router-ID is elected as follows:

• Use the setting of the bgp router-id <x.x.x.x> router subcommand.

• Choose the highest numeric IP address of any up/up loopback interface, at the time the BGP process initializes.

• Choose the highest numeric IP address of any up/up non- loopback interface, at the time the BGP process initializes.

Presenter

Presentation Notes

The process is as follows: First priority is the bgp router-id command. That takes precedence over anything else Second is the highest IP address of any up/up loopback when the bgp process initializes And the final if none of the others are true, is the highest IP address of any up up non loopback interface


BGP Authentication

» To configure authentication for BGP, use the following command: • neighbor neighbor-ip password key (BGP subcommand)

» This command must be configured on both routers. » If keys do not match or this command is only

configured on one router, peer-establishment will not be formed.

Presenter

Presentation Notes

LAB DEMONSTRATION (eBGP) - Show what happens (is displayed in debugs as well as Sniffer) when any of the required Sanity checks do NOT match. ---Unexpected/misconfigured source IP address. ---Wrong AS ---Same Router-ID ---Authentication on one side but not the other. ---Authentication key mismatch

BGP Update-Source & Multihop Requirement

www.ine.com


BGP Update-Source

» TCP Connection must first form between BGP peers. » This TCP connection must form before BGP messages flow

over this TCP connection. » Source IP address used in TCP connection usually must

match what your neighbor is expecting from you in his “neighbor” command.

» The local router t ries to form a TCP connection with the IP address defined in the neighbor remote-as command.

Presenter

Presentation Notes

With IGPs such as EIGRP and OSPF, a router doesn’t care about the source ip address other than verifying that it is from a directly-connected subnet. This is because when another IGP router suddenly multicast/broadcasts, “Hello…here I am!” it is assumed that router is a trusted peer, residing within the same company/Autonomous System. - BGP does not have this implicit trust. It will only talk to routers it has been TOLD to talk to.


BGP Update-Source

» When peers are directly-connected, source-IP address of incoming BGP messages is t rusted.

1 2 1.1.1.1 1.1.1.2

AS# 1 AS# 2 router bgp 1 neighbor 1.1.1.2 remote-as 2


Fast0/0 Fast0/0

How do I reach 1.1.1.2? Oh…via FastEthernet0/ 0! I’ll use that as my source IP.

1

TCP Sync (src=1.1.1.1 dest port=179) 2

Am I configured to expect/ trust BGP from 1.1.1.1? Yes!! How do I reply back to 1.1.1.1? Oh…via FastEthernet0/ 0! I’ll use that as my source IP.

3

TCP Sync + Ack (src = 1.1.1.2 src port=179)

4 TCP ACK (179) 5


BGP Update-Source (2)

» What if peers are NOT directly connected?

1 2 1.1.1.1

3.3.3.3 AS# 1 AS# 1



Fast0/0 Fast0/0


1 1.2.1.1?? Who are you??? I don’t know you!! 3

Serial0/0 Serial0/0

1.2.1.1


TCP Reset (src = 3.3.3.3 src port=179) 4 1.2.1.2

IP Routing Table D 3.3.3.0/24 via 1.2.1.2 (Fast0/0)

Presenter

Presentation Notes

Now we’ve switched to iBGP.


BGP Update-Source (3)

» Redundant Links between connected peers

1 2

1.2.1.2 AS# 1 AS# 1



Fast0/0 Fast0/0


1 1.1.1.1? Great…I was expecting you! 3

1.2.1.1

1.1.1.2 Fast0/1 Fast0/1 1.1.1.1

0/1

0/2

0/3

0/4

IP Routing Table C 1.2.1.0/24 via Fast0/0 C 1.1.1.0/24 via Fast0/1


TCP ACK (179)

D 1.1.1.0/24 via 1.2.1.2 (Fast0/10) TCP Sync (src=1.2.1.1 dest port=179) 4

1.2.1.1?? Who are you??? I don’t know you!! 5

TCP Reset (src = 3.3.3.3 src port=179) 6


BGP Update-Source

» The failure in one link can cause BGP neighborship to fail.

» There are two solut ions to resolve this issue: • Configure two neighbor commands on each router.

• Use loopback interfaces as the TCP connection endpoints.

» The use of two BGP Peerings between the same pair of routers can consume bandwidth and more memory in the BGP table.

Presenter

Presentation Notes

If the link that the peer is built across fails, then the TCP session dies, and so does BGP! There are 2 ways we can fix this issue. 1) 2 bgp sessions. If one dies, we still have the other to advertise information 2) we can use a loopback address as the source and destination of the session instead! The second method is preferred because 2 sessions consumes more bandwidth on the links and also more memory in our BGP Table to maintain 2 peers.


BGP Update-Source (Fix# 1)

1 2 1.1.1.1

3.3.3.3 AS# 1 AS# 1

router bgp 1 neighbor 3.3.3.3 remote-as 1 neighbor 3.3.3.3 update-source Serial0/0

router bgp 1 neighbor 1.1.1.1 remote-as 1 neighbor 1.1.1.1 update-source FastEthernet0/0

Fast0/0 Fast0/0


1 I was waiting for you 1.1.1.1! 3

Serial0/0 Serial0/0

1.2.1.1


1.2.1.2

IP Routing Table D 3.3.3.0/24 via 1.2.1.2 (Fast0/0)


BGP Parallel Links (Solution #1)

1 2

1.2.1.2 AS# 1 AS# 1

router bgp 1 neighbor 1.2.1.2 remote-as 1 neighbor 1.1.1.2 remote-as 1

router bgp 1 neighbor 1.2.1.1 remote-as 1 neighbor 1.1.1.1 remote-as 1

Fast0/0 Fast0/0 1.2.1.1

1.1.1.2 Fast0/1 Fast0/1 1.1.1.1

0/1

0/2

0/3

0/4


TCP ACK (179)


TCP ACK (179)

Presenter

Presentation Notes

Although this is showing iBGP, the same type of topology could also be found with eBGP. - Two simultaneous TCP connections means BGP must work twice as hard. Also, this will result in a bloated BGP table.


BGP Parallel Links (Solution# 2)

1 2

1.2.1.2 AS# 1 AS# 1

router bgp 1 neighbor 12.12.12.12 remote-as 1 neighbor 12.12.12.12 update-source Loop0 ! ip route 12.12.12.12 255.255.255.255 1.1.1.2 ip route 12.12.12.12 255.255.255.255 1.2.1.2


Fast0/0 Fast0/0 1.2.1.1

1.1.1.2 Fast0/1 Fast0/1 1.1.1.1

0/1

0/2

0/3

0/4

IP Routing Table C 1.2.1.0/24 via Fast0/0 C 1.1.1.0/24 via Fast0/1 S 12.12.12.12/32 via 1.1.1.2 via 1.2.1.2

Loop0 12.12.12.12 / 32

Loop0 11.11.11.11 / 32


TCP ACK (179)


Presenter

Presentation Notes

CEF will decide which of the parallel, equal-cost links will be used to initiate the TCP connection. -


Case where “Update-Source” not needed

1 2 1.1.1.1 1.1.1.2

Loopback0 2.2.2.2

Router bgp <whatever> neighbor 2.2.2.2 remote-as <whatever>

Router bgp <whatever> neighbor 1.1.1.1 remote-as <whatever>

1 TCP Sync (Dest Port=179) Src=1.1.1.1 Dest = 2.2.2.2

2 TCP Sync+ACK (Source Port=179) Src=2.2.2.2 Dest = 1.1.1.1

• Notice that in this instance, Router-2 responds using it’s Loopback Interface IP Address as a source IP…even without “update-source” configured.

Presenter

Presentation Notes

Normally, you’d think that “update-source loopback0” would be required on Router-2…but in this case it works even without it. - Not a very elegant design though and people might ask you, “Ummm….WHY did you design it like that??”


eBGP Problem

1 2

1.2.1.2 AS# 1 AS# 2



Fast0/0 Fast0/0 1.2.1.1

1.1.1.2 Fast0/1 Fast0/1 1.1.1.1

0/1

0/2

0/3

0/4


Loop0 12.12.12.12 / 32

Loop0 11.11.11.11 / 32


I can’t even start the TCP process because my peer is NOT directly-connected!!

I can’t even start the TCP process because my peer is NOT directly-connected!!

Presenter

Presentation Notes

eBGP has a rule that states external peers must be directly connected. In this case, while the neighbor is physically, directly-connected, the Loopback routes are NOT displayed as directly-connected routes in the IP Routing Table. - IP packets carrying eBGP data normally have a TTL = 1. If the BGP process determines that a neighbor is not reachable using this TTL it will not even attempt to start the TCP 3-way handshake. - In this topology, Router-1 has no idea how far away 12.12.12.12 is. The static route provides no indication if that address physically resides on the next-hop…or if the next-hop will simply continue to forward packets to that destination.


eBGP Solution #1 - Multihop

1 2

1.2.1.2 AS# 1 AS# 2

router bgp 1 neighbor 12.12.12.12 remote-as 2 neighbor 12.12.12.12 update-source Loop0 neighbor 12.12.12.12 ebgp-multihop ! ip route 12.12.12.12 255.255.255.255 1.1.1.2 ip route 12.12.12.12 255.255.255.255 1.2.1.2

router bgp 2 neighbor 11.11.11.11 remote-as 1 neighbor 11.11.11.11 update-source Loop0 neighbor 11.11.11.11 ebgp-multihop ! ip route 11.11.11.11 255.255.255.255 1.1.1.2 ip route 11.11.11.11 255.255.255.255 1.2.1.2

Fast0/0 Fast0/0 1.2.1.1

1.1.1.2 Fast0/1 Fast0/1 1.1.1.1

0/1

0/2

0/3

0/4


Loop0 12.12.12.12 / 32

Loop0 11.11.11.11 / 32


TCP Sync (179) IP TTL = 255

Presenter

Presentation Notes

eBGP multihop overrides the default TTL behavior of eBGP setting it to a default value of 255. This value can be reduced as an optional keyword within the ebgp-multihop command.


eBGP Solution #2 – Disable Connected

1 2

1.2.1.2 AS# 1 AS# 2

router bgp 1 neighbor 12.12.12.12 remote-as 2 neighbor 12.12.12.12 update-source Loop0 neighbor 12.12.12.12 disable-connected-check ! ip route 12.12.12.12 255.255.255.255 1.1.1.2 ip route 12.12.12.12 255.255.255.255 1.2.1.2

router bgp 2 neighbor 11.11.11.11 remote-as 1 neighbor 11.11.11.11 update-source Loop0 neighbor 11.11.11.11 disable-connected-check ! ip route 11.11.11.11 255.255.255.255 1.1.1.2 ip route 11.11.11.11 255.255.255.255 1.2.1.2

Fast0/0 Fast0/0 1.2.1.1

1.1.1.2 Fast0/1 Fast0/1 1.1.1.1

0/1

0/2

0/3

0/4


Loop0 12.12.12.12 / 32

Loop0 11.11.11.11 / 32


TCP Sync (179) IP TTL = 1

Presenter

Presentation Notes

The command shown above disables normal eBGP rules and allows a router to start a TCP session with a remote peer in another AS that is not directly-connected. - The main difference between this command and eBGP-multihop is that the command, “disable-connected-check” is only for peering to the Loopback address of a directly-connected peer. It enforces this by setting the TTL = 1 of all outbound TCP/BGP packets.

BGP Message Types, BGP Table, & BGP Routes

www.ine.com


BGP Message Header and Types

» All BGP messages carried within IP/TCP Headers

IP Header TCP Header

Marker (All “Fs”) 16-bytes Length (2-bytes) Type (1 byte) BGP Data

» BGP uses four types of messages for its operat ion: • Open

• Update • Keepalive • Notification

Presenter

Presentation Notes

Marker, Length, and Type part of standard BGP header Marker contains MD5 Hash of Password when Authentication is used.


BGP Message Types - Open

» BGP Open Message: • Used in Neighbor Establishment

• BGP values and capabilities are exchanged.

Marker (All “Fs”) 16-bytes Length (2-bytes) Type = 1 Version = 4 My AS# Hold Time Router-ID

Optional Parameters Length BGP Capabilities

Presenter

Presentation Notes

Hold Time default = 180-seconds


BGP Open Message (Sniffer Trace)

Presenter

Presentation Notes

Technically, BGP-4 is called, “Multi Protocol BGP” because it supports a variety of AFI/SAFI protocols (not simply IPv4 unicast). - AFI = Address Family Indicator SAFI = Subsequent-Address Family Indicator - All current AFI values are in the URL below (note: it is vendor-dependent which of these AFI values their BGP implementation will support): http://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml All current SAFI values are in the URL below (note: it is vendor-dependent which of these SAFI values their BGP implementation will support): http://www.iana.org/assignments/safi-namespace/safi-namespace.xhtml


BGP Message Types - Update

» BGP Update Message: • Informs neighbors about withdrawn routes, changed routes, and new

routes.

• Used to exchange PAs and the associated prefix/length (NLRI) that use those attributes.

Marker (All “Fs”) 16-bytes Length (2-bytes) Type = 2 Unfeasible Routes

Length Withdrawn Routes (if any)

Total Path Attributes Length NLRI Prefix Length

Path Attributes (TLV)

NLRI Prefix

Presenter

Presentation Notes

BGP-4 is unique in that it can carry both IPv4 and IPv6 prefixes within it’s Update messages.


BGP Update Message (Sniffer Trace)


BGP Message Types - Notification

» BGP Notificat ion message: • Used to signal a BGP error; typically results in a reset to the neighbor

relationship

Marker (All “Fs”) 16-bytes Length (2-bytes) Type = 3

Error Code Error Subcode

Data

Presenter

Presentation Notes

1 = HDR Error (malformed BGP Message header) 2 = OPEN Error 3= UPDATE Error 4 = Hold Time Expired 5 = FSM Error 6 = Cease


BGP Notification Message (Sniffer Trace)


BGP Message Types - Keepalive

» BGP Keepalive message: • Sent on a periodic basis to maintain the neighbor relationship. The

lack of receipt of a Keepalive message within the negotiated Hold timer causes BGP to bring down the neighbor connection.

IP Header TCP Header

Marker (All “Fs”) 16-bytes Length (2-bytes) Type = 4

Presenter

Presentation Notes

Keepalive is just the BGP Header. Sent every 60-seconds by default.


BGP Keepalive Message (Sniffer Trace)


Examining the BGP Table

» To verify the BGP table, use the command show ip bgp.

» The output will list all the BGP learned routes, locally injected plus learned from neighbors.

» With each prefix it will have mult iple at t ributes that can be examined and used for best path select ion.

» Each prefix can have mult iple paths with different next-hops.

Presenter

Presentation Notes

Now on to the BGP table. Think of this like your EIGRP topology table, or OSPF database, but for BGP information. In order to look at that info, use the show ip bgp command The information in this output basically illustrates all routing information currently known by BGP Each prefix will be an entry in the BGP table, with an associated IP next hop, and then path attributes. We’ll cover the path attributes in more detail later. And each prefix can have multiple IP next hops. The next hop we choose will depend on the bgp best path selection algorithm



Presenter

Presentation Notes

**REVIEW THIS INFORMATION, HIGHLIGHT, ETC.**



» Prefixes with ‘*’ are valid to be considered for best-path algorithm.

» Best path is presented by ‘>’. » The Path heading shows the AS_Path Attribute. » The BGP show commands list the AS_Path with the

first-added ASN on the right and the last-added ASN on the left .

Presenter

Presentation Notes

**BACK UP EACH BULLET POINT TO THE PREVIOUS SLIDE TO ILLUSTRATE** Prefixes with a * are to be considered for best path selection. The carrot represents the path that was chosen as best The Path column shows us the AS_PATH attribute, which we’ll get into soon And in this output, the AS # that is farthest to the right is the AS that originated the prefix. If the column is empty, then we originated the prefix.


Verification Commands for eBGP Learned Routes

» show ip bgp prefix [subnet-mask] » show ip bgp neighbors ip-address received-routes » show ip bgp neighbors ip-address routes » show ip bgp neighbors ip-address advert ised-routes » show ip bgp summary

Presenter

Presentation Notes

Just the following commands to verify BGP information. **ILLUSTRATE EACH ONE** In this video we’ve looked at the BGP message types as well as introduced you to the BGP table… … In the next video we’ll take a look at the default best path selection process when no path attributes have been altered.

BGP Neighbor States

www.ine.com


BGP Neighbor States

» BGP goes to through the following neighborship states: » Idle: The BGP process is either administrat ively down or

await ing the next retry at tempt.

» Connect : The BGP process has detected an incoming TCP connection request and is wait ing for the TCP connection to be completed.

Presenter

Presentation Notes

So in this video we’re going to look over the states that a BGP neighbor will go through to reach a point that they can exchange information. The first is the Idle state. In this state the BGP process isn’t doing anything, and is currently either admin down or waiting a chance to retry building the neighbor The next state is connect. In this state the bgp process is waiting for the TCP session to be completed. So we’re in the process of doing the 3way handshake so that can be established.


BGP Neighbor States

» Act ive: BGP has init iated an outbound TCP connection request and is wait ing for the 3-way handshake to complete. BGP can enter this state either because: • This router was the first router to initiate a connection (from Idle-to-Active)

• This router received an initial, inbound connnection request that failed to complete the TCP handshake (Idle-Connect-Active)

» Opensent : The TCP connection exists, and a BGP Open message has been sent to the peer, but the matching Open message has not yet been received from the other router.

Presenter

Presentation Notes

Then we hit active. Active is not an indication of an error condition unless it stays in this state for more than a second or two (time for normal TCP 3-way handshake to complete). If indicative of an error, for a wide variety of reasons such as TCP was unable to start, or finish, the 3-way handshake. During the Active state BGP is still trying to initiate a TCP handshake (it never gives up). The next state is Opensent. In this state the TCP session is healthy, and we’ve sent the BGP open message to the peer, but haven’t received the Open message from the other side


BGP Neighbor States

» Openconfirm: An Open message has been both sent to and received from the other router.

» Established: All neighbor parameters match, the neighbor relat ionship works, and the peers can now exchange Update messages.

Presenter

Presentation Notes

- Once that open message is received, we hit the Openconfirm state. Once all neighbor parameters match, we’ve finally hit the established state! - NOTE: Just because two peers are in the BGP Established state does NOT necessarily mean they have exchanged BGP updates. It is possible to configure BGP without any “network” or “redistribute” commands which would result in a BGP peering but nothing to be sent to that peer (not sure WHY you’d want to do this…but you can).


Active “Initiate TCP”

State Transitions: TCP Handshake Failure

Idle “Start event” Connect “ Initiate TCP”

TCP Sync Received

Possibility #1

EXPIRED!

TCP timeout

TCP Sync+ACK

TCP Sync Transmited

ConnectRetry Timer

ConnectRetry Timer

Presenter

Presentation Notes

The output of “show ip bgp summary” will NEVER display a peer in the CONNECT state (not sure why). Even if you ARE in the “CONNECT” state this command will display as “ACTIVE”. The only way to actually see the word “connect” is with “debug ip bgp all” - - A “Start Event” is anything that informs BGP “you need to start, or process, a TCP connection with a peer”. --- -----This could be hitting the “enter” key after inputting IOS commands that provide a new BGP configuration -----A new IP route suddenly appears in the Routing Table providing reachability to a peer (where none existed before) -----An incoming TCP “sync” is received from remote BGP peer before we have a chance to invoke our own, local TCP process. -- In this example the TCP retransmission attempt fails BEFORE the ConnectRetry timer expires. So rather than waiting for it to expire, we move into the “Active” state, stop the timer and restart it. - On Cisco routers, if a TCP “Sync-Ack” is not received within 2-seconds the initial TCP Sync will be retransmitted up to three times (at intervals of 2-secs, 4-secs, and 8-secs) before declaring a TCP Retransmission Timeout. -- Per RFC 1771: “The exact value of the ConnectRetry timer is a local matter, but should be sufficiently large to allow TCP initialization.”


ConnectRetry Timer (stopped)

ConnectRetry Timer

Active “Initiate TCP”

State Transitions: TCP Resets

Idle “Start event”

TCP Sync Sent

TCP Reset Received

Possibility #2

BGP invokes/starts TCP

Presenter

Presentation Notes

In this example the TCP is immediately stopped by receipt of a TCP Reset message. This occurs BEFORE the ConnectRetry timer expires. So rather than waiting for it to expire, we stop the timer, move into the IDLE state, restart the timer, and move back to Active.


OpenSent

Moving to OpenSent

Idle “Start event” Active “ Initiate TCP”

TCP Sync Sent

TCP Sync+AcK received

Possibility #3

Send BGP “Open”

TCP AcK sent

ConnectRetry Timer

Presenter

Presentation Notes

This is what you WANT to see! - OpenSent means you have moved beyond the TCP 3-way handshake and have sent a BGP “Open” message to your peer. However you haven’t received an Open message from that peer yet.


OpenSent

Moving from OpenSent (1)

Idle ACTIVE “Initiate TCP”

Open Received but bad BGP header or bad Open parameters

BGP Notification

Presenter

Presentation Notes

In the event that there is something you don’t like about the Open Message you received from your peer (unexpected Autonomous System number, unsupported BGP options, etc) you will move back to the dreaded “Idle” state and do this process ALL OVER AGAIN.


OpenSent

Moving from OpenSent (2)

Open Confirm

Established

Open Received …everything looks good!

BGP Keepalive sent

BGP Keepalive received

I’m ready to send my BGP Update(s) now!!

Presenter

Presentation Notes

This is what you WANT to see! When you get to the Established state it means that you and your BGP peer agree on all basic parameters and you can FINALLY trade BGP Updates (if you have anything to exchange). - Some Cisco docs call it “OpenReceive” but technically…per RFC1771 this state is called, “OpenConfirm”.

BGP Peering Collisions

www.ine.com


Peering and Router-IDs

» When two routers are init ially configured to peer with each other, they don’t know each other’s BGP Router-IDs.

» Normally, the router with highest Router-ID will init iate the TCP handshake with the router that has lowest Router-ID.

» That can’t happen if Router-IDs are unknown.


BGP Collisions? » If BGP Router-IDs are unknown, a peering collision may occur.


TCP ACK (179)

TCP Sync (179)

TCP Sync + Ack (179)

TCP ACK (179)

1 2

1.2.1.2 AS# 1 AS# 2

router bgp 1 neighbor 12.12.12.12 remote-as 2 neighbor 12.12.12.12 update-source Loop0 neighbor 12.12.12.12 ebgp-multihop bgp router-id 11.11.11.11 ! ip route 12.12.12.12 255.255.255.255 1.1.1.2 ip route 12.12.12.12 255.255.255.255 1.2.1.2


Fast0/0 Fast0/0 1.2.1.1

1.1.1.2 Fast0/1 Fast0/1 1.1.1.1

0/1

0/2

0/3

0/4

Loop0 12.12.12.12 / 32

Loop0 11.11.11.11 / 32

BGP Open (RiD=11.11.11.11)

BGP Open (RiD=12.12.12.12)

Hey, I’ve already got a session with you! Hey, I’ve already got a

session with you! BGP Notification (Cease!!)

Presenter

Presentation Notes

This is demonstrated using an eBGP topology but could just as easily occur with iBGP. - Multiple equal-cost paths to reach neighbor = CEF decides which path to select. - In this case RFC 4271 states that the Router with the Highest Router-ID should retain the session it INITIATED (bottom session in this case) and the router with Lower Router-ID should KILL the session that it initiated (by sending BGP Notification message with “Cease” error code). - This killing of the session by the Lower Router-ID speaker, takes place immediately after entering the OPENCONFIRM state


How do we prevent collisions?

» Router can be configured to only accept inbound connections, but not ACTIVELY init iate outbound connections.


TCP ACK (179)

1 2

1.2.1.2 AS# 1 AS# 2

router bgp 1 neighbor 12.12.12.12 remote-as 2 neighbor 12.12.12.12 update-source Loop0 neighbor 12.12.12.12 ebgp-multihop neighbor 12.12.12.12 transport connection-mode passive bgp router-id 11.11.11.11 ! ip route 12.12.12.12 255.255.255.255 1.1.1.2 ip route 12.12.12.12 255.255.255.255 1.2.1.2


Fast0/0 Fast0/0 1.2.1.1

1.1.1.2 Fast0/1 Fast0/1 1.1.1.1

0/1

0/2

0/3

0/4

BGP Open (RiD=12.12.12.12)

Presenter

Presentation Notes

Options for this command are “Passive” and “Active”. - This command could have been placed on either router. - Without the “Active” command on Router-2, there might be a bit of a delay until Router-2 decides to initiate a connection.


Who initiated the connection?

If the “Local Port” is NOT 179 that means your local router INITIATED the TCP connection.

Defeating BGP DoS Attacks with TTL Security

www.ine.com


BGP DoS Example

1.2.1.2

AS# 1

AS# 2

router bgp 1 neighbor 1.2.1.2 remote-as 2 bgp router-id 11.11.11.11 !

router bgp 2 neighbor 1.2.1.1 remote-as 1 bgp router-id 12.12.12.12 !

Fast0/0 Fast0/0 1.2.1.1 1 2

Evil Person

BGP Notification= CEASE!! (RiD=12.12.12.12) IP TTL=4

Dest=1.2.1.1 Source=1.2.1.2

BGP Notification= CEASE!! (RiD=12.12.12.12) IP TTL=1

Dest=1.2.1.1 Source=1.2.1.2

Destination 1.2.1.1? I can forward that!

Guess I need to kill my BGP peering with

12.12.12.12!

eBGP’s reliance on TTL=1 leaves it open to attack.

Presenter

Presentation Notes

In this case, the “Evil Person” has some kind of traffic generator on his PC that is capable of creating a BGP Notification message and spoofing the source IP address. - Router-1 only accepts BGP packets from Router-2 under the condition they have a TTL of “1” because Router-2 is an eBGP peer. - Ebgp-multihop wouldn’t enforce any security either. It doesn’t care about the TTL of incoming BGP packets from a peer as long as the TTL is one (1) or greater.


TTL and eBGP Sessions

» eBGP sessions assume neighbor is direct ly-connected. » TTL in eBGP sessions set to “1” if Connected route is found. » If neighbor NOT direct ly connected, addit ional configurat ion

needed to start BGP peering process (which affects outbound TTL) • eBGP-multihop (sets TTL in outbound BGP packets to 255)

• Disable-connected-check (sets TTL to “1” in outbound BGP packets.

• TTL-Security (to be discussed next)


TTL-Security

» By default , any TTL value (>0) of received BGP packets is accepted from eBGP peers.

» TTL-Security = Mechanism to enforce TTL values to prevent DoS • (config-rtr)#neighbor x.x.x.x ttl-security hops <1-254>

» How is “hops” used? • 255 - <hops> = X

• All incoming BGP packets must have TTL ≥ X

Presenter

Presentation Notes

TTL-Security is a feature that was designed to protect your router from malicious DoS attacks coming from OUTSIDE of your Autonomous System. - It is assumed that you have control over your own Autonomous-System and people from within your own company aren’t trying to bring down your routers.


TTL-Security with Direct-Connection Peering

1.2.1.2

AS# 1 (customer) AS# 2 (ISP)

Fast0/0 Fast0/0 1.2.1.1 1 2

Evil Person neighbor 1.2.1.2 ttl-security hops 1 neighbor 1.2.1.1 ttl-security hops 1

1 BGP packets sent with TTL=255

R1 R2

2 BGP packets received-and-processed with TTL ≥ 254

R1 R2

Attacker TTL=255 3 BGP packets silently discarded with TTL < 254 R1

TTL=252

x Y

TTL=254 TTL=253

Presenter

Presentation Notes

TTL-Security (like ebgp-multihop) affects the TTL of outbound BGP packets by setting them to 255. Normally, when connected to a directly-connected eBGP peer the TTL is set to 1 in transmitted packets. - Cisco Configuration Guides state that TTL-Security should be configured on both BGP peers. - In this situation, that would be mandatory. - If this feature were only to be configured on Router-1 and not Router-2: ---Router-2 would see Router-1 as a directly-connected peer and generate BGP packets with the default TTL of 1. ---Router-1 would drop those packets from Router-2 because of TTL-Security (they don’t have a TTL of 254, or 255). - - If the attacker were directly-connected to Router-2 then conceivably he could thwart TTL security. However that would imply that the attacker resided within the ISPs Autonomous System (possibly as an employee) which means…you’ve got much bigger problems to worry about.


TTL-Security with Multihop Peering

2.2.2.2


1.2.1.1 1 2

Evil Person neighbor 2.2.2.2 ttl-security hops 2 neighbor 1.2.1.1 ttl-security hops 2


R1 R2


R1 R2

Attacker TTL=255 3 BGP packets silently discarded with TTL < 252 R1

TTL=250

x Y

TTL=254 TTL=253

a b

Presenter

Presentation Notes

This feature cannot be used along with eBGP-Multihop feature. They are mutually exclusive. -


TTL-Security with Loopback Peering (Method #1)

1.2.1.2


1.2.1.1 1 2

neighbor 22.22.22.22 update-source loop0 neighbor 22.22.22.22 ttl-security hops 2

neighbor 22.22.22.22 update-source loop0 neighbor 11.11.11.11 ttl-security hops 2


R1 R2


R1 R2

3 BGP packets silently discarded with TTL < 253 R1

Loop0 11.11.11.11 /32 Loop0

22.22.22.22 /32


TTL-Security with Loopback Peering (Method #2)

1.2.1.2


1.2.1.1 1 2

neighbor 22.22.22.22 update-source loop0 neighbor 22.22.22.22 ttl-security hops 1 neighbor 22.22.22.22 disable-connected-check

neighbor 11.11.11.11 update-source loop0 neighbor 11.11.11.11 ttl-security hops 1 neighbor 11.11.11.11 disable-connected-check


R1 R2


R1 R2

3 BGP packets silently discarded with TTL < 254 R1

Loop0 11.11.11.11 /32 Loop0

22.22.22.22 /32

Presenter

Presentation Notes

Although TTL-Security is described in Cisco documentation as a security mechanism for checking received packets, we’ve already seen that it also influences outbound packets (by setting their TTL to 255). - If the TTL-Security feature is given a hopcount of “1” it automatically assumes the peer must be directly-connected (even though it will STILL cause egress BGP packets to be transmitted with a TTL of 255). In this case, if the IP address the router is trying to peer with (Loopback of remote router) is NOT directly-connected TTL-Security (with a hopcount of “1”) will prevent the router from even starting the BGP process. - For the reason stated above, in this topology the additional command of “disable-connected-check” is needed. Recall that TTL-Security is mutually exclusive of the command “ebgp-multihop” so those two commands cannot be used together for the same peer.

BGP Neighbor Failure Detection

www.ine.com


Neighbor Failures – Direct Connections

» BGP neighbors may be direct ly, or indirect ly connected. » Failures of direct-connection = immediate teardown of BGP

peer.

1 2 1.1.1.1 1.1.1.2

AS# 1 AS# 2 router bgp 1 neighbor 1.1.1.2 remote-as 2


Fast0/0 Fast0/0


Neighbor Failures – Indirect Connections » Indirect neighbor failures rely on BGP Holddown t imer = 180-seconds.

Presenter

Presentation Notes

Clearly, there is a need to minimize the time it takes for a BGP peer to detect an indirect link failure. - The main thing to be concerned with here is that your BGP router may have learn tens of thousands (or hundreds of thousands) of routes from your BGP peer. If there is a temporary link failure (link down for only a few seconds) it may be a better idea to just leave BGP up (believing the peer still is reachable) rather than immediately tear down the peering and then have to relearn all of those routes again a few seconds later.


Adjusting BGP Timers

» BGP Keepalives can be reduced to a minimum of 1-second with a minimum holdtime of 3-secs.

Presenter

Presentation Notes

The “holdtime” value (second number to be configured) is advertised in BGP Open messages to your peer. - Timers can also be adjusted per-BGP-peer with the “neighbor x.x.x.x timers” command. - THE PROBLEM: Reducing the Keepalive and Holddown timers affects the CPU of the router (more frequent TCP packets to send/receive). With many neighbors, this can negatively impact CPU.


Other ways of failure detection

» Several other options exist for neighbor failure detect ion which don’t affect CPU: • Neighbor Fall-Over

• Neighbor Fall-Over Route-Map

• Neighbor Fall-Over BFD

» All of the above are called, “BGP Fast Peering Session Deact ivat ion”

Presenter

Presentation Notes

The main idea is to quickly discern when a BGP peer is no longer reachable…but not rely on TCP/BGP Keepalives for that information.


Neighbor Fall-Over

» The “neighbor x.x.x.x fall-over” command has several options:

• Tracks IGP route to BGP peer (iBGP or eBGP). When route is lost, peer immediately taken down.

• Does NOT work if router ALSO contains a default route.


Neighbor Fall-Over


Loopback0 11.11.11.11

Loopback0 22.22.22.2


Without “neighbor fall-over”, Holddown Timer must expire.

1 2 1.1.1.1 1.1.1.2

AS# 1 Fast0/0 Fast0/0

EIGRP

neighbor 22.22.22.2 fall-over neighbor 11.11.11.11 fall-over

Presenter

Presentation Notes

What is interesting here is that even though the router has lost its physical connection to the neighbor, BGP somehow doesn’t KNOW that it has lost its route to its peer. Instead it must purely rely on lost BGP keepalives to become aware that its peer is unreachable.


Neighbor Fall-Over – The Problem

router bgp 1 neighbor 1.1.1.2 remote-as 1 neighbor 199.11.1.3 remote-as 1 neighbor 199.11.1.3 fall-over

Loop0 199.11.1.3/ 32

1 1.1.1.2 7.7.7.2

ISP-B: BGP AS# 1

Fast0/0

EIGRP AS 100

2 3

iBGP peering

iBGP peering iBGP peering

Loop0 199.10.1.1/ 32

Corporate Intranet Routers

199.11.0.0/16 via Rtr-X!! 199.10.0.0 /16

via Rtr-Y!! A C

ISP-A ISP-C

router bgp 1 neighbor 7.7.7.2 remote-as 1 neighbor 199.10.1.1 remote-as 1 neighbor 199.10.1.1 fall-over

199.11.x.x/16 199.10.x.x/16

X Y

Presenter

Presentation Notes

In this example we have an ISP’s Autonomous System (ISP-B) which is being used as a Transit AS for other ISPs. Router-1 and Router-3 have learned of each other’s Loopbacks as /32 host routes via EIGRP/Router-2. - In an effort to reduce the IP Routing Table size on routers-1, 2 and 3, all of the intranet routes have been aggregated by Router-X and Router-Y down to 199.10.x.x/16 or 199.11.x.x/16. In other words: -------All subnets to the right of the dashed line start with 199.11.x.x. These are being aggregated by Router-X. -------All subnets to the left of the dashed line start with 199.10.x.x These are being aggregated by Router-Y. Aggregated (and default) routes cannot be used by BGP for next-hop reachability of BGP peers. - The “fall-over” command ONLY tracks IP reachability to BGP peers…it doesn’t care about what other rules BGP may impose. So when Router-1 loses its physical connectivity to Router-2, “fall-over” determines there is STILL IP reachability to Router-3 (after all, there is an aggreated-route isn’t there??) and so doesn’t report any problems to BGP. BGP process on Router-1 (and Router-3) now has to fallback to the BGP Holdtimer to expire before declaring each other unreachable.


BGP Fast Peering Session Deactivation with Next-Hop Address Tracking

» A Route-Map can be associated to the “neighbor x.x.x.x fall-over” command:

• Tracks IGP route to BGP peer (iBGP or eBGP). When route is lost, peer immediately taken down.

• Doesn’t care if a default route (or aggregate) exists or not.


Neighbor Fall-Over – The Solution!

router bgp 1 neighbor 1.1.1.2 remote-as 1 neighbor 199.11.1.3 remote-as 1 neighbor 199.11.1.3 fall-over route-map FALLOVER ! access-list 1 permit 199.11.1.3 0.0.0.0 ! Route-map FALLOVER permit 10 match ip address 1

Loop0 199.11.1.3/ 32

1 1.1.1.2 7.7.7.2 Fast0/0

EIGRP AS 100

2 3

iBGP peering


Loop0 199.10.1.1/ 32


199.11.0.0/16 via Rtr-X!! 199.10.0.0 /16

via Rtr-Y!! A C

ISP-A ISP-C

router bgp 1 neighbor 7.7.7.2 remote-as 1 neighbor 199.10.1.1 remote-as 1 neighbor 199.10.1.1 fall-over route-map FALLOVER ! access-list 1 permit 199.10.1.1 0.0.0.0 ! Route-map FALLOVER permit 10 match ip address 1

199.11.x.x/16 199.10.x.x/16

X Y

Presenter

Presentation Notes

By associating a Route-Map to the “fall-over” command, this feature now knows that if the specific route being tracked by the Route-Map disappears from the IP Routing table, it should notify the BGP process that the route is no longer reachable…even if it IS reachable via a default or aggregated route.


Indirect Link Failure

1 2

AS# 1 AS# 2

router bgp 1 neighbor 1.1.1.2 remote-as 2 neighbor a.a.a.a remote-as 3 network 7.7.7.0 mask 255.255.255.0

router bgp 2 neighbor 1.1.1.1 remote-as 1 neighbor b.b.b.b remote-as 4

1.1.1.2 Fast0/1 Fast0/1 1.1.1.1 0/2 0/4

A B

AS# 3 AS# 4

7.7.7.0/24

• Previous two solutions will not work. • Router-2 will continue to use path to Router-1 until holddown timer expires.

Presenter

Presentation Notes

In this scenario, because Router-2 has a connected route to the 1.1.1.0 subnet, that route will remain in its IP Routing Table even after Port 0/2 goes down. - Left to its default, Router-2 would wait 180-seconds before destroying the peering with Router-1 and only then would consider Router-B as the “bestpath” to reach network 7.7.7.0/24. - One possibility is to reduce the Holddown timers on both Router-1 and Router-2 which would alert R2 to neighbor-failure within 3-4 seconds. But once again, when you reduce BGP keepalive, and holddown timers you are increasing the workload of the CPU. - Is there a better way??


BFD…yes, it is a Big, Fantastic Deal!!

» BFD = Bi-Direct ional Forwarding Detect ion » Utilizes UDP and CEF » BFD session setup between BFD peers. » Sub-second failover ut ilizing BFD/UDP “pings” » Originally designed for direct ly-connected peers. » Not just for BGP.

Presenter

Presentation Notes

IP Routing (in this case BGP) must be configured PRIOR to BFD configuration. - Keep in mind that sub-second failover is not always a GOOD thing in BGP (when dealing with hundreds-of-thousands of routes) - BFD packets are typically smaller in size than IGP/BGP hello packets (less overhead) - IGP/BGP Keeplalives are generated and processed by the CPU. The faster you force them to go (decreasing timers) the more work you’re asking the CPU to do. - BFD can become complex and has a lot of variables. This presentation will not be an exhausive, in-depth discussion of BFD.


BFD Echo and Control Packets

» BFD can utilize two types of packets • Echo

• Control

» Control packets are mandatory and processed by CPU.

» Echo packets are optional (on by default). • Echo packets are not received by CPU of peer, simply test forwarding

path of peer.

• Echo packets contain source-and-destination address of the sender.

Presenter

Presentation Notes

BFD Control Packets are used to negotiate initial timers, ensure the BFD process is active on the peer, and give flags/indicators as to why a previous BFD session may have been torn down. - BFD Echo packets have the same L2 Source/Destination MAC address…and same L3 Source/destination IP address as the sender. The idea is that when received by the peer, they will simply be looked up by the forwarding engine and echoed back to the source. - In the case where the peer’s forwarding engine is implemented in hardware (like CEF), the CPU of the peer shouldn’t even see these packets. - Echo mode packets can be sent MUCH more frequently than Control packets and provide a much faster method of failure detection without any CPU impact to the peer.


BFD Basic Configuration

» Init ial BFD timers configured on physical interface. » Echo Mode on by default

• Router(config-if)#bfd interval 100 min_rx 200 multiplier 3

“I would like to transmit BFD Echo packets every 100msecs”! “The fastest I can process incoming

BFD ECHO packets is every 200msecs so please don’t send

them any faster”!

“If YOUR min_rx is LESS than my interval, I’ll respect your value and transmit Echo packets at that rate. And

I’ll declare you dead after 3x that value”!

Presenter

Presentation Notes

When using BFD in Echo Mode…Control Packets are not used to detect neighbor failure. Only Echo packets are used for that because they are being sent much more frequently than Control Packets.


Indirect Link Failure with BFD

1 2

AS# 1 AS# 2

Interface FastEthernet0/1 ip address 1.1.1.1 255.255.255.252 bfd interval 100 min_rx 100 multiplier 3 ! router bgp 1 neighbor 1.1.1.2 remote-as 2 neighbor 1.1.1.2 fall-over bfd neighbor a.a.a.a remote-as 3 network 7.7.7.0 mask 255.255.255.0

Interface FastEthernet0/1 ip address 1.1.1.2 255.255.255.252 bfd interval 100 min_rx 100 multiplier 3 ! router bgp 2 neighbor 1.1.1.1 remote-as 1 neighbor 1.1.1.1 fall-over bfd neighbor b.b.b.b remote-as 4

1.1.1.2 Fast0/1 Fast0/1 1.1.1.1 0/2 0/4

A B

AS# 3 AS# 4

7.7.7.0/24

Presenter

Presentation Notes

LAB DEMONSTRATION!!! -- bfd interval100 min_rx 100 multiplier 3 - Send BFD packets every 100ms - Must receive BFD packets from peer (min_rx) at LEAST every 100ms. - After 3-lost BFD packets (multiplier 3) declare neighbor dead and report to whatever feature (BGP in this case) is using BFD. - BFD negotiates between peers. So the slowest interval will be selected if timers are mismatched.


Indirect Link Failure with BFD (1)

1 2

AS# 1 AS# 2

! router bgp 1 neighbor 22.22.22.22 remote-as 2 neighbor 22.22.22.22 ebgp-multihop neighbor 22.22.22.22 update-source loopback0 neighbor 1.3.1.3 remote-as 3 network 7.7.7.0 mask 255.255.255.0 ! Ip route 22.22.22.22 255.255.255.255 1.1.1.2

! router bgp 2 neighbor 11.11.11.11 remote-as 1 neighbor 11.11.11.11 ebgp-multihop neighbor 11.11.11.11 update-source loopback0 neighbor 2.4.2.4 remote-as 4 ! Ip route 11.11.11.11 255.255.255.255 1.1.1.1

1.1.1.2 Fast0/1 Fast0/1 1.1.1.1 0/2 0/4

A B AS# 3 AS# 4

7.7.7.0/24

Loop0 11.11.11.11 / 32

Loop0 22.22.22.22/ 32

1.3.1.3 2.4.2.4

1.3.1.1 2.4.2.2

Multihop peers can be reachable via several physical links. Upon which link should BFD be configured?

Presenter

Presentation Notes

Because BFD was originally designed to operate with directly-connected peers, the previous configuration shown won’t work between Router-1 and Router-2.


Indirect Link Failure with BFD (2)

1 2

AS# 1 AS# 2

bfd-template multi-hop BGP interval min-tx 200 min-rx 200 multiplier 3 ! bfd map ipv4 22.22.22.22/32 0.0.0.0/0 BGP ! router bgp 1 neighbor 22.22.22.22 remote-as 2 neighbor 22.22.22.22 ebgp-multihop neighbor 22.22.22.22 update-source loopback0 neighbor 22.22.22.22 fall-over bfd multihop neighbor 1.3.1.3 remote-as 3 network 7.7.7.0 mask 255.255.255.0 ! Ip route 22.22.22.22 255.255.255.255 1.1.1.2

bfd-template multi-hop BGP interval min-tx 200 min-rx 200 multiplier 3 ! bfd map ipv4 11.11.11.11/32 0.0.0.0/0 BGP ! router bgp 2 neighbor 11.11.11.11 remote-as 1 neighbor 11.11.11.11 ebgp-multihop neighbor 11.11.11.11 update-source loopback0 neighbor 11.11.11.11 fall-over bfd multihop neighbor 2.4.2.4 remote-as 4 ! Ip route 11.11.11.11 255.255.255.255 1.1.1.2

1.1.1.2 Fast0/1 Fast0/1 1.1.1.1 0/2 0/4

A B AS# 3 AS# 4

7.7.7.0/24

Loop0 11.11.11.11 / 32

Loop0 22.22.22.22/ 32 1.3.1.3 2.4.2.4

1.3.1.1 2.4.2.2

Presenter

Presentation Notes

In this case, BFD is not configured on any physical interface, because to reach our multihop neighbor, any one of MANY interfaces could be utilized. - Instead of configuring your BFD parameters within an interface, you configure it within a BFD template. In this case, “BGP” is just a descriptive name for the Template. - The BFD map command tells the router what destination to send BFD packets to “22.22.22.22 in this case on Router-1” and what source to send those packets from. By using 0.0.0.0/0 as the source, this frees the router to use ANY interface it has which can reach that destination IP address. - There are also “single-hop” BFD templates which are primarily used when you want to have different BGP authentication or Dampening parameters per-neighbor.


Quiz!!!

Given the configurations shown above, answer these questions: 1. How often will Router-1 receive BFD Echo packets from Router-2? ____________

2. How long will it take for Router-2 to tear down the BGP peering session with

Router-1 when port 0/2 on the switch goes down? ____________


Answer

Given the configurations shown above, answer these questions: 1. How often will Router-1 receive BFD Echo packets from Router-2? Every

300mSecs

2. How long will it take for Router-2 to tear down the BGP peering session with Router-1 when port 0/2 on the switch goes down? After roughly 900msecs.

Presenter

Presentation Notes

Remember, you will send BFD Echo packets as fast as your neighbor supports…even if they are faster than what you originally WANTED to send with your “interval” value.


Quiz!!! Loop0

33.33.33.33/ 32

1 Fast0/0 Fast0/0

EIGRP AS 100

2 3

iBGP peering


Loop0 11.11.11.11/ 32


0.0.0.0/0 via Rtr-X (EIGRP) A

C

ISP-A ISP-C

X Y

Which of the features that we’ve learned about in this series would quickly teardown the iBGP Peering between Router-1 and Router-3 if FastEthernet0/0 on Router-1 went down…WITHOUT consuming any additional bandwidth on any of the links shown here?


Answer Loop0

199.11.1.3/ 32

1 1.1.1.2 7.7.7.2 Fast0/0

EIGRP AS 100

2 3

iBGP peering


Loop0 199.10.1.1/ 32


199.11.0.0/16 via Rtr-X!! 199.10.0.0 /16

via Rtr-Y!! A C

ISP-A ISP-C

199.11.x.x/16 199.10.x.x/16

X Y

BGP Fast Peering Session Deactivation with Next-Hop Address Tracking

Presenter

Presentation Notes

BFD would be the quickest failure-detection method…however BFD requires frequent sending/receiving of BFD packets between peers. The question specifically said we were NOT allowed to consume additional bandwidth on the links…which leaves us with the only other option of BGP Fast Peering Session Deactivation with Next-Hop Address Tracking. - Normal BGP Fast Peering Session Deactivation would not work because of the default-route that has been learned via EIGRP.

Copyright © www.ine.com All rights reserved.

Q&A

Documents

BGP Part-1 - Cloud Object Storage | Store & Retrieve Data ... Part-1 Prerequisite knowledge required:\爀 圀栀愀琀 椀猀 愀渀 䄀甀琀漀渀漀洀漀甀猀 匀礀猀琀攀洀

BGP Part-1 - Cloud Object Storage | Store & Retrieve Data ... Part-1 Prerequisite knowledge required:\爀圀栀愀琀椀猀愀渀䄀甀琀漀渀漀洀漀甀猀匀礀猀琀攀洀