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.
