CCNA Basics | Cisco Advanced | Linux
Lab Topology | eBGP Peering
SOLUTIONS
EIGRP Configurations
First an easy part.
On all routers/switches:
On R5 (S1/0 interface is a multipoint one). Another command must be added:
R5 Config:
!
interface serial1/0
no ip split-horizon eigrp 1
!
EIGRP Verification
Now, that I have verified that I see all the loopbacks (all routers are runnning EIGRP), I can remove them from EIGRP.
On all routers/switches:
BGP neighbor statement must match the source IP address of the peer sending BGP Open message.
For instance, if R1 is to peer with R3, the latter (R3) must have a neighbor statement specifying IP address of R1 who's sending the BGP Open message. This example is easy, because they are directly connected. But it is not so obvious what src IP R1 is going to use sending Open message to R2. Let's see the direct peering first.
R1 peering with R3
In order for R1 to reach 10.1.13.3 (R3), the outgoing is going to be S1/1 interace:
R1#show ip route 10.1.13.3
Routing entry for 10.1.13.0/24
Known via "connected", distance 0, metric 0 (connected, via interface)
Redistributing via eigrp 1
Routing Descriptor Blocks:
* directly connected, via Serial1/1
Route metric is 0, traffic share count is 1
R1#
R1#show run int s1/1
!
interface Serial1/1
ip address 10.1.13.1 255.255.255.0
serial restart-delay 0
!
In fact, this is the lab so I can take risks here, which I would not try on the production machine. Below is the debug of IP packets on R1 pinging R3 (10.1.13.3) and R3 pinging R1 (10.1.13.1).
NEVER USE THIS DEBUG ON THE PRODUCTION SYSTEM !
R1(config)#access-list 1 permit 10.1.13.1
R1(config)#end
R1#debug ip packet detail 1
IP packet debugging is on (detailed) for access list 1
R1#
R1#ping 10.1.13.1 repeat 1
FIBipv4-packet-proc: route packet from (local) src 10.1.13.1 dst 10.1.13.1
FIBfwd-proc: Default:10.1.13.1/32 receive entry
FIBipv4-packet-proc: packet routing failed
IP: tableid=0, s=10.1.13.1 (local), d=10.1.13.1 (Serial1/1), routed via RIB
IP: s=10.1.13.1 (local), d=10.1.13.1 (Serial1/1), len 100, sending
ICMP type=8, code=0
Directly connected networks have Administrative Distance 0, which is the most trusted. That's why R1 and R3 won't consider any other path (many available here) to reach each other.
Now, I am ready to configure iBGP Peering between R1 and R3.
R1 Config:
!
router bgp 1
bgp log-neighbor-changes
neighbor 10.1.13.3 remote-as 1
!
Since, the respective configuration on R3 has not been done yet, BGP cannot establish TCP session (R3 socket is not listening on port 179 just yet). Here's the behavior of such TCP session establishment attempt:
R1#debug ip tcp transactions
TCP special event debugging is on
TCBF3E670A0 created
TCBF3E670A0 setting property TCP_VRFTABLEID (20) F22CE1FC
TCBF3E670A0 setting property TCP_MD5KEY (4) 0
TCBF3E670A0 setting property TCP_ACK_RATE (37) F3254C08
TCBF3E670A0 setting property TCP_TOS (11) F3254C24
TCBF3E670A0 setting property TCP_PMTU (45) F3254BB0
TCBF3E670A0 setting property TCP_RTRANSTMO (36) F3254C04
TCP: Random local port generated 63024, network 1
TCBF3E670A0 bound to 10.1.13.1.63024
Reserved port 63024 in Transport Port Agent for TCP IP type 1
TCP: sending SYN, seq 4018291362, ack 0
TCP0: Connection to 10.1.13.3:179, advertising MSS 1460
TCP0: state was CLOSED -> SYNSENT [63024 -> 10.1.13.3(179)]
Released port 63024 in Transport Port Agent for TCP IP type 1 delay 240000
TCP0: state was SYNSENT -> CLOSED [63024 -> 10.1.13.3(179)]
TCP0: bad seg from 10.1.13.3 -- closing connection: port 63024 seq 0 ack 4018291363 rcvnxt 0 rcvwnd 0 len 0
TCP0: connection closed - remote sent RST
TCB 0xF3E670A0 destroyed
R1#u all
All possible debugging has been turned off
R1 is picking an ephemeral port (semi-randomly) 63024 (tcp src port):
TCP: Random local port generated 63024
then, it is creating TCP Control Block:
TCBF3E670A0 bound to 10.1.13.1.63024
R1 is sending SYN packet towards 10.1.13.3 port 179 (BGP) and is receiving RST in reply (R3 has not been configured to open TCP port 179)
TCP: sending SYN, seq 4018291362
TCP0: connection closed - remote sent RST
Completing R1 to R3 iBGP peering:
R3 Config:
!
router bgp 1
bgp log-neighbor-changes
neighbor 10.1.13.1 remote-as 1
!
Now, the peering is complete.
R1#show ip bgp summary
BGP router identifier 172.16.1.1, local AS number 1
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.1.13.3 4 1 4 4 1 0 0 00:00:40 0
R1#
R1#show ip bgp neighbor 10.1.13.3
BGP neighbor is 10.1.13.3, remote AS 1, internal link
BGP version 4, remote router ID 172.16.3.3
BGP state = Established, up for 00:01:35
Here's how the peering between R1 and R2 (not a directly adjacent router) is going to look like.
How does R1 reach R2 (10.1.0.2)?
R1#show ip route 10.1.0.2
Routing entry for 10.1.0.0/24
Known via "connected", distance 0, metric 0 (connected, via interface)
Redistributing via eigrp 1
Routing Descriptor Blocks:
* directly connected, via Serial1/0
Route metric is 0, traffic share count is 1
R1#
R1#show run int s1/0
interface Serial1/0
ip address 10.1.0.1 255.255.255.0
R1 will use S1/0 interface (10.1.0.1) as its source to reach R2 (10.1.0.2). Thus, the R2's neighbor statement must point to 10.1.0.1. Conversly, R2 will use its S1/0 interface (10.1.0.2) as the src IP for BGP open packet towards 10.1.0.1. R1 neighbor statement must be 10.1.0.2 to accept BGP Open message.
Here's the config to create R1 to R2 peering:
R1 Config:
!
router bgp 1
neighbor 10.1.0.2 remote-as 1
!
R2 Config:
!
router bgp 1
bgp log-neighbor-changes
neighbor 10.1.0.1 remote-as 1
!
R2#show ip bgp neighbors 10.1.0.1 | i internal|Neighbor|state|TTL
BGP neighbor is 10.1.0.1, remote AS 1, internal link
BGP state = Established, up for 00:03:24
Neighbor sessions:
Neighbor capabilities:
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 255
R2#
R2#show tcp brief | i 10.1.0.1
F3270560 10.1.0.2.179 10.1.0.1.29446 ESTAB
R2#
Summary
Lab Topology | eBGP Peering
TASK
- Configure EIGRP AS 1 on all routers.
- Configure full mesh iBGP peering using BGP AS 1.
- Advertise loopback0 into BGP ensuring full reachability.
SOLUTIONS
EIGRP Configurations
First an easy part.
On all routers/switches:
!
router eigrp 1
network 10.0.0.0
network 172.16.0.0
!
On R5 (S1/0 interface is a multipoint one). Another command must be added:
R5 Config:
!
interface serial1/0
no ip split-horizon eigrp 1
!
EIGRP Verification
Now, that I have verified that I see all the loopbacks (all routers are runnning EIGRP), I can remove them from EIGRP.
On all routers/switches:
!
router eigrp 1
no network 172.16.0.0
!
BGP neighbor statement must match the source IP address of the peer sending BGP Open message.
For instance, if R1 is to peer with R3, the latter (R3) must have a neighbor statement specifying IP address of R1 who's sending the BGP Open message. This example is easy, because they are directly connected. But it is not so obvious what src IP R1 is going to use sending Open message to R2. Let's see the direct peering first.
R1 peering with R3
In order for R1 to reach 10.1.13.3 (R3), the outgoing is going to be S1/1 interace:
R1#show ip route 10.1.13.3
Routing entry for 10.1.13.0/24
Known via "connected", distance 0, metric 0 (connected, via interface)
Redistributing via eigrp 1
Routing Descriptor Blocks:
* directly connected, via Serial1/1
Route metric is 0, traffic share count is 1
R1#
R1#show run int s1/1
!
interface Serial1/1
ip address 10.1.13.1 255.255.255.0
serial restart-delay 0
!
In fact, this is the lab so I can take risks here, which I would not try on the production machine. Below is the debug of IP packets on R1 pinging R3 (10.1.13.3) and R3 pinging R1 (10.1.13.1).
NEVER USE THIS DEBUG ON THE PRODUCTION SYSTEM !
R1(config)#access-list 1 permit 10.1.13.1
R1(config)#end
R1#debug ip packet detail 1
IP packet debugging is on (detailed) for access list 1
R1#
R1#ping 10.1.13.1 repeat 1
FIBipv4-packet-proc: route packet from (local) src 10.1.13.1 dst 10.1.13.1
FIBfwd-proc: Default:10.1.13.1/32 receive entry
FIBipv4-packet-proc: packet routing failed
IP: tableid=0, s=10.1.13.1 (local), d=10.1.13.1 (Serial1/1), routed via RIB
IP: s=10.1.13.1 (local), d=10.1.13.1 (Serial1/1), len 100, sending
ICMP type=8, code=0
Directly connected networks have Administrative Distance 0, which is the most trusted. That's why R1 and R3 won't consider any other path (many available here) to reach each other.
Now, I am ready to configure iBGP Peering between R1 and R3.
R1 Config:
!
router bgp 1
bgp log-neighbor-changes
neighbor 10.1.13.3 remote-as 1
!
Since, the respective configuration on R3 has not been done yet, BGP cannot establish TCP session (R3 socket is not listening on port 179 just yet). Here's the behavior of such TCP session establishment attempt:
R1#debug ip tcp transactions
TCP special event debugging is on
TCBF3E670A0 created
TCBF3E670A0 setting property TCP_VRFTABLEID (20) F22CE1FC
TCBF3E670A0 setting property TCP_MD5KEY (4) 0
TCBF3E670A0 setting property TCP_ACK_RATE (37) F3254C08
TCBF3E670A0 setting property TCP_TOS (11) F3254C24
TCBF3E670A0 setting property TCP_PMTU (45) F3254BB0
TCBF3E670A0 setting property TCP_RTRANSTMO (36) F3254C04
TCP: Random local port generated 63024, network 1
TCBF3E670A0 bound to 10.1.13.1.63024
Reserved port 63024 in Transport Port Agent for TCP IP type 1
TCP: sending SYN, seq 4018291362, ack 0
TCP0: Connection to 10.1.13.3:179, advertising MSS 1460
TCP0: state was CLOSED -> SYNSENT [63024 -> 10.1.13.3(179)]
Released port 63024 in Transport Port Agent for TCP IP type 1 delay 240000
TCP0: state was SYNSENT -> CLOSED [63024 -> 10.1.13.3(179)]
TCP0: bad seg from 10.1.13.3 -- closing connection: port 63024 seq 0 ack 4018291363 rcvnxt 0 rcvwnd 0 len 0
TCP0: connection closed - remote sent RST
TCB 0xF3E670A0 destroyed
R1#u all
All possible debugging has been turned off
R1 is picking an ephemeral port (semi-randomly) 63024 (tcp src port):
TCP: Random local port generated 63024
then, it is creating TCP Control Block:
TCBF3E670A0 bound to 10.1.13.1.63024
R1 is sending SYN packet towards 10.1.13.3 port 179 (BGP) and is receiving RST in reply (R3 has not been configured to open TCP port 179)
TCP: sending SYN, seq 4018291362
TCP0: connection closed - remote sent RST
Completing R1 to R3 iBGP peering:
R3 Config:
!
router bgp 1
bgp log-neighbor-changes
neighbor 10.1.13.1 remote-as 1
!
Now, the peering is complete.
R1#show ip bgp summary
BGP router identifier 172.16.1.1, local AS number 1
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.1.13.3 4 1 4 4 1 0 0 00:00:40 0
R1#
R1#show ip bgp neighbor 10.1.13.3
BGP neighbor is 10.1.13.3, remote AS 1, internal link
BGP version 4, remote router ID 172.16.3.3
BGP state = Established, up for 00:01:35
Here's how the peering between R1 and R2 (not a directly adjacent router) is going to look like.
How does R1 reach R2 (10.1.0.2)?
R1#show ip route 10.1.0.2
Routing entry for 10.1.0.0/24
Known via "connected", distance 0, metric 0 (connected, via interface)
Redistributing via eigrp 1
Routing Descriptor Blocks:
* directly connected, via Serial1/0
Route metric is 0, traffic share count is 1
R1#
R1#show run int s1/0
interface Serial1/0
ip address 10.1.0.1 255.255.255.0
R1 will use S1/0 interface (10.1.0.1) as its source to reach R2 (10.1.0.2). Thus, the R2's neighbor statement must point to 10.1.0.1. Conversly, R2 will use its S1/0 interface (10.1.0.2) as the src IP for BGP open packet towards 10.1.0.1. R1 neighbor statement must be 10.1.0.2 to accept BGP Open message.
Here's the config to create R1 to R2 peering:
R1 Config:
!
router bgp 1
neighbor 10.1.0.2 remote-as 1
!
R2 Config:
!
router bgp 1
bgp log-neighbor-changes
neighbor 10.1.0.1 remote-as 1
!
R2#show ip bgp neighbors 10.1.0.1 | i internal|Neighbor|state|TTL
BGP neighbor is 10.1.0.1, remote AS 1, internal link
BGP state = Established, up for 00:03:24
Neighbor sessions:
Neighbor capabilities:
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 255
R2#
R2#show tcp brief | i 10.1.0.1
F3270560 10.1.0.2.179 10.1.0.1.29446 ESTAB
R2#
Summary
- BGP Neighbor statement must match the peer's IP address which is used to start BGP session
- iBGP peerings are configured with the SAME AS number
- iBGP peerings use TTL 255 by default which means that BGP peers do not have to be directly connected
- TCP Port 179 is used to establish connection
- Reachability to the Neighbor Address is necessary to establish TCP connection
- In rare case both routers started the session only one session is preserved
- Initiator of the TCP session picks ephemeral port (above 1023) as the source port with TCP 179 port as the destination
