Simple BGP Multi-home Topology Part 1 – Neighboring with loopback adresses

Consider the following topology:

BGP-Topo
Customer has hired two different ISP’s for their redundant internet connection. The two ISP ‘s do not have any relationship with eachother and only provide Broadband Internet Access for the customer.
Both ISP’s run BGP as their routing protocol. The customer runs OSPF on their internal network and want to provide access to a few networks from the outside world.

We start with setting up each BGP AS and BGP relationships to both ISP’s to exchange routing information and want to use loopback addresses voor peering the eBGP peers.
BGP depends on an IGP to contact neighbors and they do not have to be direct neighbors. In this case the IGP is static routing to the neighbor adresses, but you can also use OSPF, EIGRP, IS-IS or MPLS as an IGP depending on the topology.

As with BGP we know that there is no discovery mechanisme for detecting neighbors. You must manually configure them between routers. Peering happens on basis of TCP over port 179. And this port will be opened as soon as the local bgp neighbor is configured.

Configure Basic IP:

 
CUSTOMER#
interface Loopback1
description *** eBGP PEER TO ISP1 ***
ip address 1.1.1.1 255.255.255.255
!
interface Loopback2
description *** eBGP PEER TO ISP2 ***
ip address 1.1.1.2 255.255.255.255
!
interface FastEthernet0/0
ip address 172.16.1.2 255.255.255.254
speed 100
full-duplex
!
interface FastEthernet0/1
ip address 172.16.1.4 255.255.255.254
speed 100
full-duplex
CUSTOMER#

ISP1#
interface Loopback0
description *** eBGP PEER TO CUSTOMER ***
ip address 3.3.3.3 255.255.255.255
!
interface FastEthernet0/0
ip address 172.16.1.3 255.255.255.254
speed 100
full-duplex
!
ISP1#

ISP2#
interface Loopback0
description *** eBGP PEER TO CUSTOMER ***
ip address 4.4.4.4 255.255.255.255
!
interface FastEthernet0/1
 ip address 172.16.1.4 255.255.255.254
 duplex full
 speed 100
!

Configure IGP:

CUSTOMER#
ip route 3.3.3.3 255.255.255.255 172.16.1.3 name BGP_NEIGH_ISP1
ip route 4.4.4.4 255.255.255.255 172.16.1.5 name BGP_NEIGH_ISP2
CUSTOMER#

ISP1#
ip route 1.1.1.1 255.255.255.255 172.16.1.2 name BGP_NEIGH_CUST
ISP1#

ISP2#
ip route 1.1.1.2 255.255.255.255 172.16.1.4 name BGP_NEIGH_CUST
ISP2#

Configure basic BGP:

CUSTOMER#sh run | sec bgp
router bgp 64200
 no synchronization
 bgp log-neighbor-changes
 neighbor 3.3.3.3 remote-as 64310
 neighbor 4.4.4.4 remote-as 64510
 no auto-summary
CUSTOMER#

ISP1#sh run | sec bgp
router bgp 64310
 no synchronization
 bgp log-neighbor-changes
 neighbor 1.1.1.1 remote-as 64200
 no auto-summary
ISP1#

ISP2#sh run | sec bgp
router bgp 64510
 no synchronization
 bgp log-neighbor-changes
 neighbor 1.1.1.2 remote-as 64200
 no auto-summary
ISP2#

Output:

CUSTOMER#sh ip bgp summary 
BGP router identifier 192.168.4.1, local AS number 64200
BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
3.3.3.3         4 64310      57      58        0    0    0 00:00:20 Idle
4.4.4.4         4 64510      57      58        0    0    0 00:00:20 Idle

Idle state is not good. Here’s the explaination:
Idle State:
• Refuse all incoming BGP connections
• Start the initialization of event triggers.
• Initiates a TCP connection with its configured BGP peer.
• Listens for a TCP connection from its peer.
• Changes its state to Connect.
• If an error occurs at any state of the FSM process, the BGP session is
terminated immediately and returned to the Idle state. Some of the reasons why a router does not progress from the Idle state are:
TCP port 179 is not open.
A random TCP port over 1023 is not open.
Peer address configured incorrectly on either router.
AS number configured incorrectly on either router.

BGP default sends it’s routing information out the interface where the IGP believes (according to the routing table) it must be sent to. In this case for node CUSTOMER it will be 172.16.1.3 for neighbor 3.3.3.3 and 172.16.1.5 for neighbor 4.4.4.4.
But both ISP1 and ISP2 are configured for 1.1.1.1 and 1.1.1.2, so here’s a mismatch. BGP Packets will be dropped because they do not match with the corresponding neighbor.
We need to define a source-interface per neighbor to ensure a match between the peers
Let’s configure the following:

CUSTOMER#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
CUSTOMER(config)#router bgp 64200
CUSTOMER(config-router)#neighbor 3.3.3.3 update-source lo1
CUSTOMER(config-router)#neighbor 4.4.4.4 update-source lo2
CUSTOMER(config-router)#end
CUSTOMER#

ISP1#
ISP1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
ISP1(config)#router bgp 64310
ISP1(config-router)#neighbor 1.1.1.1 update-source lo0
ISP1(config-router)#end

ISP2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
ISP2(config)#router bgp 64510
ISP2(config-router)#neighbor 1.1.1.2 update-source lo0
ISP2(config-router)#end
ISP2#

Now we have a match!! But the neighbors are still in Idle state!?
Since the loopback addresses are not tied to a routed exit interface it requires an extra hop to reach the loopback address.
Configure the following neighbor command on each BGP neighbor config:

CUSTOMER#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
CUSTOMER(config)#router bgp 64200
CUSTOMER(config-router)#neighbor 4.4.4.4 ebgp-multihop 2
CUSTOMER(config-router)#neighbor 3.3.3.3 ebgp-multihop 2

I’ve turned on debug on node ISP1 before configuring the eBGP Multihop and update-source and this is the result:

*Mar  1 01:22:58.567: BGP: 1.1.1.1 went from Idle to Active
*Mar  1 01:22:58.575: BGP: 1.1.1.1 open active delayed 34286ms (35000ms max, 28% jitter)
ISP1#
*Mar  1 01:23:00.679: BGP: 1.1.1.1 passive open to 3.3.3.3
*Mar  1 01:23:00.679: BGP: 1.1.1.1 went from Active to Idle
*Mar  1 01:23:00.679: BGP: 1.1.1.1 went from Idle to Connect
*Mar  1 01:23:00.683: BGP: 1.1.1.1 rcv message type 1, length (excl. header) 26
*Mar  1 01:23:00.683: BGP: 1.1.1.1 rcv OPEN, version 4, holdtime 180 seconds
*Mar  1 01:23:00.683: BGP: 1.1.1.1 went from Connect to OpenSent
*Mar  1 01:23:00.683: BGP: 1.1.1.1 sending OPEN, version 4, my as: 64310, holdtime 180 seconds
*Mar  1 01:23:00.683: BGP: 1.1.1.1 rcv OPEN w/ OPTION parameter len: 16
*Mar  1 01:23:00.683: BGP: 1.1.1.1 rcvd OPEN w/ optional parameter type 2 (Capability) len 6
*Mar  1 01:23:00.683: BGP: 1.1.1.1 OPEN has CAPABILITY code: 1, length 4
*Mar  1 01:23:00.683: BGP: 1.1.1.1 OPEN has MP_EXT CAP for afi/safi: 1/1
*Mar  1 01:23:00.683: BGP: 1.1.1.1 rcvd OPEN w/ optional parameter type 2 (Capability) len 2
*Mar  1 01:23:00.683: BGP: 1.1.1.1 OPEN has CAPABILITY code: 128, length 0
*Mar  1 01:23:00.683: BGP: 1.1.1.1 OPEN has ROUTE-REFRESH capability(old) for all address-families
*Mar  1 01:23:00.683: BGP: 1.1.1.1 rcvd OPEN w/ optional parameter type 2 (Capability) len 2
*Mar  1 01:23:00.683: BGP: 1.1.1.1 OPEN has CAPABILITY code: 2, length 0
*Mar  1 01:23:00.683: BGP: 1.1.1.1 OPEN has ROUTE-REFRESH capability(new) for all address-families 
BGP: 1.1.1.1 rcvd OPEN w/ remote AS 64200
*Mar  1 01:23:00.683: BGP: 1.1.1.1 went from OpenSent to OpenConfirm
*Mar  1 01:23:00.683: BGP: 1.1.1.1 send message type 1, length (incl. header) 45
*Mar  1 01:23:00.703: BGP: 1.1.1.1 went from OpenConfirm to Established
*Mar  1 01:23:00.703: %BGP-5-ADJCHANGE: neighbor 1.1.1.1 Up

Let’s check the output commands:

ISP1#sh ip bgp summary 
BGP router identifier 3.3.3.3, local AS number 64310
BGP table version is 5, main routing table version 5
4 network entries using 468 bytes of memory
4 path entries using 208 bytes of memory
2/1 BGP path/bestpath attribute entries using 248 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 948 total bytes of memory
BGP activity 8/4 prefixes, 8/4 paths, scan interval 60 secs

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
1.1.1.1         4 64200      67      65        5    0    0 00:04:56        4

We are exchanging routing information and have received 4 prefixes from CUSTOMER.
Let’s check the BGP topology table:

ISP1#sh ip bgp         
BGP table version is 13, local router ID is 3.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 192.168.1.0      1.1.1.1                  0             0 64200 ?
*> 192.168.2.0      1.1.1.1                  0             0 64200 ?
*> 192.168.3.0      1.1.1.1                  0             0 64200 ?
*> 192.168.4.0      1.1.1.1                  0             0 64200 ?

4 received prefixes which will be inserted into the routing table.
But what about the ? in the column Path? Doesn’t BGP know where the prefixes originated from?

Let’s Continue on Simple BGP Multi-home Topology Part 2 – Originate IGP

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s