Thursday, October 22, 2020

MainPage


Latest Posts: 

Every Admin needs to Code! Start Learning Python Today. Everyday!


Cisco Basics (CCNA level)  Lessons:

01 - Connecting to Cisco Console Port with MINICOM
02 - Navigating in Cisco IOS
03 - Initial Configuration of Cisco Switch and Router
04 - Introduction to TCP/IP Layers
05 - Encapsulation and De-enapsulation Process
06 - Example of TCP/IP Traffic Flow
07 - Building a Home Network
08 - Ethernet and Hub Operations
09 - Bridging/Switching Learning Process
10 - Cisco Discovery Protocol
11 - Layer 2 Connectivity Troubleshooting Part 1
12 - Layer 2 Connectivity Troubleshooting Part 2
13 - Layer 2 Connectivity Troubleshooting Part 3
14 - NTP and Syslog Services
15 - VLANs Overview
16 - VLANs In Practice
17 - Inter VLAN Traffic Flow Analysis
18 - VTP and VLAN Quiz
19 - Spanning-Tree Protocol Overview
20 - Spanning-Tree Protocol Operation
21 - Spanning-Tree Protocol in Practice
22 - Spanning-Tree Cisco Enhancements
23 - Introduction to Rapid STP (802.1w)
24 - Layer 2 Etherchannel
25 - Switch Port Security
26 - Binary World
27 - IPv4 Address Dissected - Part 1
28 - IPv4 Address Dissected - Part 2
29 - IPv4 Subnetting - The Rules
30 - IPv4 Subnetting - Practice
31 - What is a Router?
32 - Route Selection Process Demistified
33 - Static Routing
34 - Dynamic Routing Protocols Introduction
35 - Routing Information Protocol Part 1
36 - Routing Information Protocol Part 2
37 - Routing Information Protocol Part 3
38 - OSPF Fundamentals Part 1 - Terminology
39 - OSPF Fundamentals Part 2 - Hello Packets
40 - OSPF Fundamentals Part 3 - RouterID and DR/BDR
41 - OSPF Fundamentals Part 4 - Implementation
42 - OSPF Fundamentals Part 5 - The Lab
43 - EIGRP Fundamentals Part 1 - Overview
44 - EIGRP Fundamentals Part 2 - Implementation
45 - EIGRP Fundamentals Part 3 - The Lab
46 - EIGRP Fundamentals Part 4 - Troubleshooting
47 - Packet Filtering with Standard ACL
48 - Standard ACL Examples
49 - Packet Filtering with Extended ACLs
50 - Extended ACL Examples
51 - Network Address Translation Part 1 - Terminology
52 - Network Address Translation Part 2 - Principles of Operation
53 - Network Address Translation Part 3 - Overloading Addresses
54 - Network Address Translation Part 4 - Configuration Examples
55 - Introduction to IPv6 Part 1 - Addresses
56 - Introduction to IPv6 Part 2 - Address Structure
57 - Introduction to IPv6 Part 3 - Address Configuration
58 - Introduction to IPv6 Part 4 - Migration 


How to install and Use IOS on Linux.


Disclaimer!
This is a personal weblog. The opinions expressed here represent my own and not those of my employer. Also the stupidity is mine and mine alone. Some post content might be rude, offensive or borderline obnoxious (anything marked with label 'Ranting' is not suitable for people under 18 years old). Since, I try to have an open mind you can expect that my opinions may and probably will change in time. You may leave some comments but I reserve the right to ignore them completely. 


The technical content of this blog is a product of weekend/sleepless-and-or-hotel night/after-work technical struggle. Despite all efforts, it may be inaccurate and reflects the author's knowledge as of the time of writing the posts. The author of the posts will not assume any liability or responsibility to any person or entity with respect to loss or damages incurred from information contained in this blog. Any resemblance to some other training materials and/or CCNA/CCNP/CCIE exams is completely coincidental.



Tuesday, October 20, 2020

Cisco-Next-Step

Home | Next Step | Cisco | Linux



Getting deeper into routing and switching.
 

 

BGP Routing Protocol Observations

08. eBGP Multi Hop 

iBGP Route Reflector

 

Previous | Cisco | Next


 

So far, building our BGP network I have accomplished the following:

  • Created eBGP peering between R2 (AS65100) and R8 (AS65089).
  • Created iBGP peering between R2 and R4 using their respective Loopback0 interfaces to form a BGP session.

Now, let's fix the problem of BGP prefixes advertisement between R1 and R4 over iBGP.

Here's the BGP table on R1:

R1#show ip bgp
BGP table version is 13, local router ID is 10.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *>  10.1.1.1/32      0.0.0.0                  0         32768 i
 *>i 10.2.2.2/32      172.16.123.2             0    100      0 i
 *>i 10.8.0.0/28      172.16.123.2             0    100      0 65089 i
 *>i 10.8.0.16/28     172.16.123.2             0    100      0 65089 i
 *>i 10.8.0.32/28     172.16.123.2             0    100      0 65089 i
 *>i 10.8.0.48/28     172.16.123.2             0    100      0 65089 i
 *>i 10.8.8.8/32      172.16.123.2             0    100      0 65089 i
 *>i 10.8.80.0/24     172.16.123.2             0    100      0 65089 i
 *>i 10.8.81.0/24     172.16.123.2             0    100      0 65089 i
 *>i 10.8.82.0/24     172.16.123.2             0    100      0 65089 i
 *>i 10.8.83.0/24     172.16.123.2             0    100      0 65089 i
 *>i 198.51.100.0     172.16.123.2             0    100      0 65089 i
R1#

Clearly, all is good here. R1 has 172.16.123.2 as its next hop IP towards the destination (next-hop-self command on R2). It receives all the prefixes that R2 is getting over eBGP from R8.

But what does the BGP table look like on R4 that is peering with R1?

R4#show ip bgp
BGP table version is 2, local router ID is 10.4.4.4
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 r>i 10.1.1.1/32      10.1.1.1                 0    100      0 i
R4#

There are no BGP routes we expect to see. There is only 10.1.1.1 (R1's Loopback0). Since we are getting it via EIGRP as well, the lower AD of EIGRP will make this entry 'rib-failure' in BGP. The BGP protocol will not be used on R4 to install this one. R2 will rather rely on EIGRP as a better source of routing information.

R4#show ip bgp rib-failure 
  Network            Next Hop                      RIB-failure   RIB-NH Matches
10.1.1.1/32        10.1.1.1            Higher admin distance              n/a
R4#
R4#show ip route 10.1.1.1
Routing entry for 10.1.1.1/32
  Known via "eigrp 10", distance 90, metric 409600, type internal
  Redistributing via eigrp 10
  Last update from 172.16.14.1 on Ethernet0/0.14, 01:07:02 ago
  Routing Descriptor Blocks:
  * 172.16.104.1, from 172.16.104.1, 01:07:02 ago, via Ethernet0/1
      Route metric is 409600, traffic share count is 1
      Total delay is 6000 microseconds, minimum bandwidth is 10000 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1
    172.16.14.1, from 172.16.14.1, 01:07:02 ago, via Ethernet0/0.14
      Route metric is 409600, traffic share count is 1
      Total delay is 6000 microseconds, minimum bandwidth is 10000 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1
R4#

That, we already know.

Is R1 even trying to advertising prefixes learned from R2 towards R1?

R1#show ip bgp neighbor 10.4.4.4 advertised-routes 
BGP table version is 13, local router ID is 10.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *>  10.1.1.1/32      0.0.0.0                  0         32768 i


It does not advertise them at all. But why?

In order to avoid internal routing loops, BGP uses its own 'bgp split-horizon' rule. It stipulates that prefixes learned via iBGP, CANNOT be advertised over an iBGP session.

There are a number of ways around that.

  • Use BGP Route-Reflectors (explained in this post).
  • Use iBGP full-mesh connectivity. This one may be hard to implement with a lot of routers as it falls under n(n-1)/2 formula, where 'n' is the number of routers involved.
  • Use BGP Confederations.

I will tackle the last two options in later posts, but for now in order to enable connectivity between R4 and AS 65089, I will use Route-Reflector. 

In the simplest scenario, BGP Route-Reflector is a router that has iBGP sessions established to all other neighbors that need the prefixes. It will a 'sort of' break the rule of split-horizon and forward the prefixes to other neighbors based on the admin's configuration.

Simply put, Route-Reflector is the central router that can advertise BGP prefixes to all other routers.

Route-Reflector can have three types of neighbors:

  • eBGP Peer
  • Client Peer
  • Non-client Peer

Given that, RR (route-reflector) will follow a few rules:

 

Routes learned from eBGP neighbors will be forwarded to ALL peers (eBGP, client, non-client).

Routes learned from client peers will be forwarded to All peers (eBGP, client, non-client).

Routes learned from non-client peers, will be forwarded to eBGP and clients.


Take a look at the above topology. R1 has currently an iBGP connectivity with R2 and R4. In a moment I will add R5 to the mix (blue arrows indicate iBGP sessions). It is a candidate to become a Route-Reflector.

I am going to start with advertising Loopback0 from R4, so that AS 65089 is receiving.

R4#show run | s router bgp 
router bgp 65100
 bgp log-neighbor-changes
 network 10.4.4.4 mask 255.255.255.255
 neighbor 10.1.1.1 remote-as 65100
 neighbor 10.1.1.1 update-source Loopback0
R4#


The BGP table on R4 looks like this:

R4#show ip bgp | begin Network 
     Network          Next Hop            Metric LocPrf Weight Path
 r>i 10.1.1.1/32      10.1.1.1                 0    100      0 i
 *>  10.4.4.4/32      0.0.0.0                  0         32768 i
R4#

I am ready to advertise (reflect) routes learned from AS 65089 towards R4. The R1 router will become a route reflector with R4 (and later R5) as its client.

R1#show run | section router bgp
router bgp 65100
 bgp log-neighbor-changes
 network 10.1.1.1 mask 255.255.255.255
 neighbor 10.4.4.4 remote-as 65100
 neighbor 10.4.4.4 update-source Loopback0
 neighbor 10.4.4.4 route-reflector-client
 neighbor 172.16.123.2 remote-as 65100
R1#

BGP session between R1 and R4 has been re-established upon this change. What are the results then?

Since the output of 'show ip bgp neighbor 10.4.4.4' is rather large, I will check it this way:

R1#show ip bgp neighbors 10.4.4.4 | include Route-Reflector
  Route-Reflector Client
R1#

R4 is now a route-reflector client.

So, can R4 see all the prefixes previously missing?

R4#show ip bgp | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 r>i 10.1.1.1/32      10.1.1.1                 0    100      0 i
 *>i 10.2.2.2/32      172.16.123.2             0    100      0 i
 *>  10.4.4.4/32      0.0.0.0                  0         32768 i
 *>i 10.8.0.0/28      172.16.123.2             0    100      0 65089 i
 *>i 10.8.0.16/28     172.16.123.2             0    100      0 65089 i
 *>i 10.8.0.32/28     172.16.123.2             0    100      0 65089 i
 *>i 10.8.0.48/28     172.16.123.2             0    100      0 65089 i
 *>i 10.8.8.8/32      172.16.123.2             0    100      0 65089 i
 *>i 10.8.80.0/24     172.16.123.2             0    100      0 65089 i
 *>i 10.8.81.0/24     172.16.123.2             0    100      0 65089 i
 *>i 10.8.82.0/24     172.16.123.2             0    100      0 65089 i
 *>i 10.8.83.0/24     172.16.123.2             0    100      0 65089 i
 *>i 198.51.100.0     172.16.123.2             0    100      0 65089 i
R4#
It worked.

Now onto the iBGP session between R1 and R5. This time I will ensure that R5 is a route-reflector client.

Let's start with removing 'passive-interface' command on R1 in order to establish EIGRP adjacency:

Configuration on R1:

router eigrp 10
 network 10.1.1.1 0.0.0.0
 network 172.16.0.0
 passive-interface Ethernet0/0.15
 eigrp router-id 10.1.1.1


Removing the command is simple:

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#router eigrp 10
R1(config-router)#no passive-interface ethernet0/0.15
R1(config-router)#
R1(config-router)#
R1(config-router)#do show ip eigrp interfaces
EIGRP-IPv4 Interfaces for AS(10)
                              Xmit Queue   PeerQ        Mean   Pacing Time   Multicast    Pending
Interface              Peers  Un/Reliable  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes
Lo0                      0        0/0       0/0           0       0/0            0           0
Et0/0.14                 1        0/0       0/0           4       0/2           50           0
Et0/0.123                1        0/0       0/0           5       0/2           50           0
Et0/1                    1        0/0       0/0           6       0/2           50           0
Et0/0.15                 0        0/0       0/0           0       0/0            0           0          

In the above output it is clear that R1 will start sending 'hello' packets over its Ethernet0/0.15 interface.

Now, onto the R1 BGP configuration:

R1#show run | s router bgp 
router bgp 65100
 bgp log-neighbor-changes
 network 10.1.1.1 mask 255.255.255.255
 neighbor 10.4.4.4 remote-as 65100
 neighbor 10.4.4.4 update-source Loopback0
 neighbor 10.4.4.4 route-reflector-client
 neighbor 172.16.15.5 remote-as 65100
 neighbor 172.16.15.5 route-reflector-client
 neighbor 172.16.123.2 remote-as 65100
R1#

Obviously, R5 needs a respective eigrp and BGP configuration.

R5#show run | section router eigrp
router eigrp 10
network 172.16.0.0
R5#

R5#show run | section router bgp router bgp 65100 bgp log-neighbor-changes network 10.5.5.5 mask 255.255.255.255 neighbor 172.16.15.1 remote-as 65100 R5#

When RR receives a route over iBGP session, it tags it internally to know that it comes from a client. This way it know which neighbors the prefix should be forwarded to.

R1#show ip bgp 10.5.5.5
BGP routing table entry for 10.5.5.5/32, version 17
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     1          2         
  Refresh Epoch 1
  Local, (Received from a RR-client)
    172.16.15.5 from 172.16.15.5 (10.5.5.5)
      Origin IGP, metric 0, localpref 100, valid, internal, best
R1#

Apart from that, when RR is advertising prefixes it will include two extra attributes (more on those in later posts).

  • Originator ID
  • Cluster List

They will ensure a loop free topology.

R2#show ip bgp 10.5.5.5
BGP routing table entry for 10.5.5.5/32, version 15
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     1         
  Refresh Epoch 2
  Local
    172.16.15.5 (metric 307200) from 172.16.123.1 (10.1.1.1)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Originator: 10.5.5.5, Cluster list: 10.1.1.1
R2#

A final connectivity test between the two Autonomous Systems.

Ping from R4 to R8:

R4#ping 10.8.8.8 source loopback0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.8.8.8, timeout is 2 seconds:
Packet sent with a source address of 10.4.4.4 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
R4#

And ping test from R5.

R5#ping 10.8.8.8 source loopback0 
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.8.8.8, timeout is 2 seconds:
Packet sent with a source address of 10.5.5.5 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
R5#

Onto the next one :)


Monday, October 19, 2020

BGP Upate Source

 




BGP protocol uses TCP for transportation. We have already observed that BGP server must approve IP address of the client packet. We use 'neighbor ip-address' command to accomplish that.


The IP address of the SYN packet from the client will be the address of the outgoing (Egress) interface according to the routing table. Let's see that in the example.

From the previous lab we got R2 to peer with R8 and R1 using eBGP. Also R2 has R1 as it BGP neighbor using iBGP connections (they are both in the same AS 65100).

R2#show ip bgp summary
BGP router identifier 10.2.2.2, local AS number 65100
BGP table version is 13, main routing table version 13
12 network entries using 1776 bytes of memory
12 path entries using 768 bytes of memory
3/3 BGP path/bestpath attribute entries using 408 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 2976 total bytes of memory
BGP activity 12/0 prefixes, 12/0 paths, scan interval 60 secs

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
172.16.28.8     4        65089      26      26       13    0    0 00:20:11       10
172.16.123.1    4        65100      25      26       13    0    0 00:19:33        1
R2#

Also, in the previous lab we learned that eBGP learned prefixes are propagated to other iBGP Peers. R2 learn prefixes from R8 are going to be passed onto R1 (iBGP peer) unchanged. Since R1 does not know how to reach 172.16.28.8 (next-hop for the prefixes advertised to R2 from R8), it would not install them into the routing table as the next hop is unreachable).

To alleviate this, we have explored a bunch of methods (check previous lab) and in this configuration I have left the 'next-hop-self' to rectify that). The config of R2 looks like so: 

R2#show run | section router bgp 
router bgp 65100
 bgp log-neighbor-changes
 network 10.2.2.2 mask 255.255.255.255
 neighbor 172.16.28.8 remote-as 65089
 neighbor 172.16.123.1 remote-as 65100
 neighbor 172.16.123.1 next-hop-self
R2#

Now, let's consider another iBGP peering between R1 and R4. 

There are two directly connected paths between R1 and R4. R1 can use the subnet 172.16.14.0/24 or 172.16.104.0/24 to reach R4.

In order to facilitate what comes next, let's create a EIGRP AS 10 process in our BGP AS 65100. This will involve EIGRP configuration on R1, R2, and R4 like so:

R1#show run | section router eigrp 
router eigrp 10
 network 172.16.0.0
passive-interface Ethernet0/0.15 eigrp router-id 10.1.1.1 R1#

I have chosen to use one network command rather than ip addresses with network wildcard mask. The implication of that approach is that eigrp 'hello' packets will be sent out of all interfaces with IP address 172.16.x.y. I intend to build eigrp adjacency with R2 and R4. For the moment, I do not want to establish eigrp adjacency with R5 though. In order to stop sending 'hello' packets to R5, I am making Eth0/0/15 a 'passive-interface' in eigrp.

The interfaces that participate in eigrp are as follows:

R1#show ip eigrp interfaces  
EIGRP-IPv4 Interfaces for AS(10)
                              Xmit Queue   PeerQ        Mean   Pacing Time   Multicast    Pending
Interface              Peers  Un/Reliable  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes
Et0/0.14                 0        0/0       0/0           0       0/0            0           0
Et0/0.123                0        0/0       0/0           0       0/0            0           0
Et0/1                    0        0/0       0/0           0       0/0            0           0
R1#

   

Let's complete the EIGRP configuration on R2.

R2#show run | section router eigrp 
router eigrp 10
 network 172.16.0.0
 eigrp router-id 10.2.2.2
R2#

And finally the EIGRP configuration on R4 node. This time, I would like to be more precise in terms of interfaces running EIGRP. I want only interfaces towards R1 to send/receive hellos. Here is the configuration:

R4#show run | section router eigrp 
router eigrp 10
 network 172.16.14.4 0.0.0.0
 network 172.16.104.4 0.0.0.0
 eigrp router-id 10.4.4.4
R4#

A quick verification on R1 to see if all the EIGRP neighbors are set up shows this:

R1#show ip eigrp neighbors 
EIGRP-IPv4 Neighbors for AS(10)
H   Address                 Interface              Hold Uptime   SRTT   RTO  Q  Seq
                                                   (sec)         (ms)       Cnt Num
2   172.16.104.4            Et0/1                    12 00:03:09    1   100  0  8
1   172.16.14.4             Et0/0.14                 14 00:03:21   10   100  0  7
0   172.16.123.2            Et0/0.123                14 00:06:35    8   100  0  3
R1#

All seems to be in order.

Now, that basic EIGRP is fully functional, let's advertise Loopback0 interfaces into EIGRP on R1 and R4.

R1#show run | section router eigrp
router eigrp 10
 network 10.1.1.1 0.0.0.0
 network 172.16.0.0
 passive-interface Ethernet0/0.15
 eigrp router-id 10.1.1.1
R1#

I will do the same on R4. Why I am doing this? You will see in a moment.

R4#show run | section router eigrp  
router eigrp 10
 network 10.4.4.4 0.0.0.0
 network 172.16.14.4 0.0.0.0
 network 172.16.104.4 0.0.0.0
 eigrp router-id 10.4.4.4
R4#

The reasons to advertise Loopback0 interfaces on both is to create two equal paths between them. Check this out:

R1#show ip route 10.4.4.4
Routing entry for 10.4.4.4/32
  Known via "eigrp 10", distance 90, metric 409600, type internal
  Redistributing via eigrp 10
  Last update from 172.16.14.4 on Ethernet0/0.14, 00:02:36 ago
  Routing Descriptor Blocks:
  * 172.16.104.4, from 172.16.104.4, 00:02:36 ago, via Ethernet0/1
      Route metric is 409600, traffic share count is 1
      Total delay is 6000 microseconds, minimum bandwidth is 10000 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1
    172.16.14.4, from 172.16.14.4, 00:02:36 ago, via Ethernet0/0.14
      Route metric is 409600, traffic share count is 1
      Total delay is 6000 microseconds, minimum bandwidth is 10000 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1
R1#

In the same way, R4 has two paths to Loopback0 of R1 router.

This is done for a reason. When I establish iBGP peering between R1 and R4, I am going to use Loopback0 interface to do so. This way, in case of any of the interfaces (Ethernet0/1 or Ethernet0/0.14) failure, the iBGP session will remain intact using the alternate route that is still working between those two Loopback0 interfaces.

Here's is the BGP configuration on R1 towards R4.

R1#show run | section router bgp
router bgp 65100
 bgp log-neighbor-changes
 network 10.1.1.1 mask 255.255.255.255
 neighbor 10.4.4.4 remote-as 65100
 neighbor 10.4.4.4 update-source Loopback0
 neighbor 172.16.123.2 remote-as 65100
R1#

Notice, that R1 is going to try to establish TCP (and eventually iBGP) session with R2 using its source ip address 10.1.1.1 (its loopback0 interface). To see that happen, let's go extra mile and check this using debug.

R1(config)#access-list 100 permit ip any host 10.4.4.4
R1(config)#end
R1#debug ip packet detail 100
IP packet debugging is on (detailed) for access list 100
R1#
FIBipv4-packet-proc: route packet from (local) src 10.1.1.1 dst 10.4.4.4
FIBfwd-proc: Default:10.4.4.4/32 process level forwarding
FIBfwd-proc: depth 0 first_idx 1 paths 2 long 0(0)
FIBfwd-proc: try path 1 (of 2) v4-anh-172.16.104.4-Et0/1 first short ext 0(-1)
FIBfwd-proc: v4-anh-172.16.104.4-Et0/1 valid
FIBfwd-proc: ip_pak_table 0 ip_nh_table 65535 if Ethernet0/1 nh 172.16.104.4 deag 0 chg_if 0 via fib 0 path type attached nexthop
FIBfwd-proc: packet routed to Ethernet0/1 172.16.104.4(0)
FIBipv4-packet-proc: packet routing succeeded
FIBfwd-proc: ip_pak_table 0 ip_nh_table 65535 if Ethernet0/1 nh 172.16.104.4 uhp 1 deag 0 ttlexp 0
R1#
FIBfwd-proc: sending link IP ip_pak_table 0 ip_nh_table 65535 if Ethernet0/1 nh 172.16.104.4 uhp 1 deag 0 chgif 0 ttlexp 0 rec 0
IP: s=10.1.1.1 (local), d=10.4.4.4 (Ethernet0/1), len 44, sending
    TCP src=62126, dst=179, seq=4214154337, ack=0, win=16384 SYN
IP: s=10.1.1.1 (local), d=10.4.4.4 (Ethernet0/1), len 44, sending full packet
    TCP src=62126, dst=179, seq=4214154337, ack=0, win=16384 SYN
R1#u all
All possible debugging has been turned off
R1#

If R4 is to accept this invitation, it must authorize the attempt sourced from 10.1.1.1.

The following configuration on R4 should do the trick.

R4#show run | section router bgp
router bgp 65100
 bgp log-neighbor-changes
 neighbor 10.1.1.1 remote-as 65100
 neighbor 10.1.1.1 update-source Loopback0
R4#

The iBGP session is now fully established.

R1#show ip bgp summary | begin Neighbor
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.4.4.4        4        65100       9      11       13    0    0 00:04:41        0
172.16.123.2    4        65100     268     267       13    0    0 03:58:50       11
R1#


R4#show ip bgp summary | begin Neighbor
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.1.1.1        4        65100       9       7        2    0    0 00:03:04        1
R4#

At this stage, there are two questions that might pop in your mind. 

Why does R4 learn only 1 prefix? The answer to that question deserves another post.

The second question regards R1 advertising the 10.1.1.1/32 towards R2. Now, R1 uses both BGP and EIGRP, what will R2 accept into its routing table?

Let's see what happened there:

R2#show ip bgp | i 10.1.1.1
 r>i 10.1.1.1/32      172.16.123.1             0    100      0 i
R2#
R2#
R2#
R2#show ip route 10.1.1.1
Routing entry for 10.1.1.1/32
  Known via "eigrp 10", distance 90, metric 409600, type internal
  Redistributing via eigrp 10
  Last update from 172.16.123.1 on Ethernet0/0.123, 01:24:55 ago
  Routing Descriptor Blocks:
  * 172.16.123.1, from 172.16.123.1, 01:24:55 ago, via Ethernet0/0.123
      Route metric is 409600, traffic share count is 1
      Total delay is 6000 microseconds, minimum bandwidth is 10000 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1
R2#

The BGP table on R2 show this prefix. However it is marked with r> which stands for 'rib failure' ( routing information base failure). Instead, R2 installs that using EIGRP, But why is that?

Do you remember the Cisco 'Administrative Distance', arbitrarily set for different routing protocols?

iBGP AD = 200
EIGRP AD = 90

The lower the value of AD, the more likely it is for the router to install the prefix.

The EIGRP AD of () is lower than iBGP 200. Thus, EIGRP wins here.

Cisco Is Easy - Main

  Cisco Basics (CCNA level)  Lessons: Watch Video Tutorials on Youtube 01 - Connecting to Cisco Console Port with MINICOM 02 - Navigatin...