Monday, February 18, 2019

Cisco Advanced

CCNA Basics | Cisco Advanced | Linux


Routing Protocols - BGP

 Lab 00 - Lab Topology
Lab 01 - iBGP Peering
Lab 02 - eBGP Peering
Lab 03 - BGP Update Source

at

EBGP Peering




iBGP Peering | BGP Update Source



TASK

  • Configure eBGP peering between R4 (AS 1) and BB3 (AS 54).
  • Configure eBGP peering between R6 (AS 1) and BB1 (AS 54).



R4 eBGP peering is going to be the first task. I would like to pay attention to some important details regarding eBGP connection.
R4 Configuration:

router bgp 1 neighbor 192.168.134.254 remote-as 54


Now, a few verification steps to make a few important observations.


R4#show ip bgp neighbor 192.168.134.254 BGP neighbor is 192.168.134.254, remote AS 54, external link BGP version 4, remote router ID 31.3.0.1 BGP state = Established, up for 00:03:51


The neighbor is in AS 54 unlike R4, which is in AS 1. That makes the BGP connection type eBGP.
This is marked with 'external link' for eBGP (internal link is iBGP).
Another very important characteristic of eBGP is that BGP uses TTL 1 (hop) by default. In iBGP connections that TTL is 255 by default (Outgoing TTL 1). This means that it is assumed that in order for eBGP connections to work, the peers (routers) must be DIRECTLY connected to each other. This can be changed and shown in later labs.

R4#show ip bgp neighbor 192.168.134.254 | i TTL Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 1


What are we learning from AS 54? Here it is:

R4#show ip bgp reg _54$ Network Next Hop Metric LocPrf Weight Path *> 28.119.16.0/24 192.168.134.254 0 0 54 i *> 28.119.17.0/24 192.168.134.254 0 0 54 i *> 114.0.0.0 192.168.134.254 0 54 i *> 115.0.0.0 192.168.134.254 0 54 i *> 116.0.0.0 192.168.134.254 0 54 i *> 117.0.0.0 192.168.134.254 0 54 i *> 118.0.0.0 192.168.134.254 0 54 i *> 119.0.0.0 192.168.134.254 0 54 i R4#


R6 Configuration:

router bgp 1 neighbor 192.168.116.254 remote-as 54


Now let's see what prefixes both R4 and R6 are learning from AS 54:

R6#show ip bgp regex ^54_ Network Next Hop Metric LocPrf Weight Path *> 28.119.16.0/24 192.168.116.254 0 54 i * i 192.168.134.254 0 100 0 54 i *> 28.119.17.0/24 192.168.116.254 0 54 i * i 192.168.134.254 0 100 0 54 i *> 112.0.0.0 192.168.116.254 0 0 54 50 60 i * i 192.168.134.254 0 100 0 54 50 60 i *> 113.0.0.0 192.168.116.254 0 0 54 50 60 i * i 192.168.134.254 0 100 0 54 50 60 i *> 114.0.0.0 192.168.116.254 0 0 54 i * i 192.168.134.254 0 100 0 54 i *> 115.0.0.0 192.168.116.254 0 0 54 i * i 192.168.134.254 0 100 0 54 i *> 116.0.0.0 192.168.116.254 0 0 54 i * i 192.168.134.254 0 100 0 54 i *> 117.0.0.0 192.168.116.254 0 0 54 i * i 192.168.134.254 0 100 0 54 i *> 118.0.0.0 192.168.116.254 0 0 54 i * i 192.168.134.254 0 100 0 54 i *> 119.0.0.0 192.168.116.254 0 0 54 i * i 192.168.134.254 0 100 0 54 i R6# R4#show ip bgp reg ^54_ Network Next Hop Metric LocPrf Weight Path * i 28.119.16.0/24 192.168.116.254 0 100 0 54 i *> 192.168.134.254 0 0 54 i * i 28.119.17.0/24 192.168.116.254 0 100 0 54 i *> 192.168.134.254 0 0 54 i * i 112.0.0.0 192.168.116.254 0 100 0 54 50 60 i *> 192.168.134.254 0 54 50 60 i * i 113.0.0.0 192.168.116.254 0 100 0 54 50 60 i *> 192.168.134.254 0 54 50 60 i * i 114.0.0.0 192.168.116.254 0 100 0 54 i *> 192.168.134.254 0 54 i * i 115.0.0.0 192.168.116.254 0 100 0 54 i *> 192.168.134.254 0 54 i * i 116.0.0.0 192.168.116.254 0 100 0 54 i *> 192.168.134.254 0 54 i * i 117.0.0.0 192.168.116.254 0 100 0 54 i *> 192.168.134.254 0 54 i * i 118.0.0.0 192.168.116.254 0 100 0 54 i *> 192.168.134.254 0 54 i * i 119.0.0.0 192.168.116.254 0 100 0 54 i *> 192.168.134.254 0 54 i R4#


Both R4 and R6 have two paths to the prefixes advertised by AS 54. Each one of them prefers its direct peer for those (marked with gt sign). Also, when advertising BGP prefixes, each one of them is going to advertise its best route only. Using iBGP advertisement, both R4 and R6 are going to preserver next-hop attribute.
At this point, it is going to be very interesting to look into BGP table on R1 which is receiving the same prefixes from R4 and R6. Here's what we get:

R1#show ip bgp regexp _54$ Network Next Hop Metric LocPrf Weight Path * i 28.119.16.0/24 192.168.116.254 0 100 0 54 i * i 192.168.134.254 0 100 0 54 i * i 28.119.17.0/24 192.168.116.254 0 100 0 54 i * i 192.168.134.254 0 100 0 54 i * i 114.0.0.0 192.168.116.254 0 100 0 54 i * i 192.168.134.254 0 100 0 54 i * i 115.0.0.0 192.168.116.254 0 100 0 54 i * i 192.168.134.254 0 100 0 54 i * i 116.0.0.0 192.168.116.254 0 100 0 54 i * i 192.168.134.254 0 100 0 54 i * i 117.0.0.0 192.168.116.254 0 100 0 54 i * i 192.168.134.254 0 100 0 54 i * i 118.0.0.0 192.168.116.254 0 100 0 54 i * i 192.168.134.254 0 100 0 54 i * i 119.0.0.0 192.168.116.254 0 100 0 54 i * i 192.168.134.254 0 100 0 54 i R1#


What is worth noticing here is that R1 gets prefixes with two different paths:
- through 192.168.116.254 (BB1) and through 192.168.134.254 (BB3)
- none of these are the best routes as R1 does not know how to reach these next-hop IP addresses
There are few ways to fix it. For now, let's advertise those networks into EIGRP that is already running on all routers. Here's the configuration:

R4(config)#router eigrp 1 R4(config-router)#network 192.168.134.0 R4(config-router)# R6(config)#router eigrp 1 R6(config-router)#network 192.168.116.0


Once R1 (and all other routers) can reach next-hop addressess: 192.168.116.254 and 192.168.134.254 via EIGRP, BGP can select the best path (grater than sign)

R1#show ip bgp regexp _54$ Network Next Hop Metric LocPrf Weight Path * i 28.119.16.0/24 192.168.116.254 0 100 0 54 i *>i 192.168.134.254 0 100 0 54 i * i 28.119.17.0/24 192.168.116.254 0 100 0 54 i *>i 192.168.134.254 0 100 0 54 i * i 114.0.0.0 192.168.116.254 0 100 0 54 i *>i 192.168.134.254 0 100 0 54 i * i 115.0.0.0 192.168.116.254 0 100 0 54 i *>i 192.168.134.254 0 100 0 54 i * i 116.0.0.0 192.168.116.254 0 100 0 54 i *>i 192.168.134.254 0 100 0 54 i * i 117.0.0.0 192.168.116.254 0 100 0 54 i *>i 192.168.134.254 0 100 0 54 i * i 118.0.0.0 192.168.116.254 0 100 0 54 i *>i 192.168.134.254 0 100 0 54 i * i 119.0.0.0 192.168.116.254 0 100 0 54 i *>i 192.168.134.254 0 100 0 54 i R1# R1#show ip route bgp Gateway of last resort is not set 28.0.0.0/24 is subnetted, 2 subnets B 28.119.16.0 [200/0] via 192.168.134.254, 00:04:58 B 28.119.17.0 [200/0] via 192.168.134.254, 00:04:58 B 112.0.0.0/8 [200/0] via 192.168.134.254, 00:04:58 B 113.0.0.0/8 [200/0] via 192.168.134.254, 00:04:58 B 114.0.0.0/8 [200/0] via 192.168.134.254, 00:04:58 B 115.0.0.0/8 [200/0] via 192.168.134.254, 00:04:58 B 116.0.0.0/8 [200/0] via 192.168.134.254, 00:04:58 B 117.0.0.0/8 [200/0] via 192.168.134.254, 00:04:58 B 118.0.0.0/8 [200/0] via 192.168.134.254, 00:04:58 B 119.0.0.0/8 [200/0] via 192.168.134.254, 00:04:58 172.16.0.0/16 is variably subnetted, 11 subnets, 2 masks B 172.16.2.0/24 [200/0] via 10.1.0.2, 03:19:38 B 172.16.3.0/24 [200/0] via 10.1.13.3, 03:19:38 B 172.16.4.0/24 [200/0] via 10.1.146.4, 03:19:07 B 172.16.5.0/24 [200/0] via 10.1.0.5, 03:19:10 B 172.16.6.0/24 [200/0] via 10.1.146.6, 03:19:18 B 172.16.7.0/24 [200/0] via 10.1.67.7, 03:19:38 B 172.16.8.0/24 [200/0] via 10.1.58.8, 03:19:15 B 172.16.9.0/24 [200/0] via 10.1.79.9, 03:19:12 B 172.16.10.0/24 [200/0] via 10.1.108.10, 03:19:07 R1#


In the above output it is I can see that the next-hop for AS 54 network is 192.168.134.254 (BB3).
The question is what does R1 advertise to its peer R3? Is it going to be both paths or only the best? As per BGP rules, only the best path is further advertised.
Let's see one of those prefixes on R1 in more detail. Pay attention which path is the best. Then take a look at what R3 receives from R1.

R1#show ip bgp 112.0.0.0 BGP routing table entry for 112.0.0.0/8, version 24 Paths: (2 available, best #1, table default) Not advertised to any peer Refresh Epoch 1 54 50 60 192.168.134.254 (metric 307200) from 10.1.146.4 (172.16.4.4) Origin IGP, metric 0, localpref 100, valid, internal, best Refresh Epoch 1 54 50 60 192.168.116.254 (metric 2195456) from 10.1.146.6 (172.16.6.6) Origin IGP, metric 0, localpref 100, valid, internal R1# R1#show ip bgp neighbor 10.1.13.3 advertised-routes Network Next Hop Metric LocPrf Weight Path *> 172.16.1.0/24 0.0.0.0 0 32768 i Total number of prefixes 1 R1#


What? Only one prefix is being advertised (the one that belongs to R1)?
Of course, this is as expected. R1 is learning AS 54 prefixes from R4 and R6 over iBGP session.
BGP split-horizon rule stipulates that what is learned over iBGP cannot be re-advertised over another iBGP session. It is a loop prevention mechanism. Later, we will see how it can be handled. So far now we're going to leave this at that. 
Summary
  • BGP routes learned over eBGP retain original next-hop attribute
  • Prefixes learned over iBGP will NOT be advertised over iBGP sessions (BGP Split-Horizon rule)
  • BGP Router only advertises the best paths
at

Tuesday, February 12, 2019

Linux



1. TCPDUMP 1 - Basics
2. TCPDUMP 2 - IP Header

at

TCPDUMP Basics



TCPDUMP Basics | TCPDUMP IP Header

TCPDUMP is a very powerful packet capturing tool. "Must love tcpdump and wireshark" the job ads often say, so working with networks requires mastering the fundamentals of this tool.

 I have two Raspberry PI computers in my lab. They are perfect learning tools (hats off to the creators).

 TYPICAL SYNTAX

 A typical packet capture might look like this:

 pi@lucy: $ sudo tcpdump -i eth0 -s 1600 -nn -vvv src host 192.168.0.254 and dst port 22
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 1600 bytes

 What on earth do those flag stand for?
-i eth0      capture packets on eth0 interface
-s 1600    capture only 1600 bytes rather than max. allowed (varies by version)
-nn           don't resolve ip address or port numbers to names
-v             slightly more verbose output
-vv           even more verbose output
-vvv         even more verbose output (useful with -x or -X option)
src host   coming from IP address
and          logical and (both statement must be true to capture packets)
dst port    dst port 22 (ssh)

 NETWORK FILTERING
tcpdump net 192.168.0
tcpdump src net  192.168.0
tcpdump dst net 192.168.0
etc.

PROTOCOL FILTERING
tcpdump ip
tcpdump tcp
tcpdump icmp
etc. 

 Combining expressions may may involve keywords such as:

 !        negation
not    negation

 &       concatenation
and    concatenation

 ||        alternative (or)
or       alternative

 Example:
pi@lucy: $ sudo tcpdump -i eth0 -s 1600 -nn -vvv -c3 'tcp and src host 192.168.0.254'

 I've thrown in -c3 (for capturing only 3 packets) and the combined expression in quotes (' ').

 Another example:
pi@lucy: $ sudo tcpdump -i eth0 -s 1600 -nn -vvv -c3 'not tcp and src host 192.168.0.254'
at
Labels:

Lab00 - Lab Topology




Creating Lab Topology | iBGP Peering


Lab 1 Topology


at

iBGP Peering

CCNA Basics | Cisco Advanced | Linux

 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


at
Subscribe to: Posts (Atom)

Cisco Is Easy - Main

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