Saturday 8 November 2014

BGP route advertisment using the network command

Hi all,

So we are have established ebgp peering with R1 and R2. Now we need to start routing traffic. To start advertising route over our bgp peer the simplest way to do this is using the network statement command.

R1#config t
R1(config)#router bgp 100
R1(config-router)#network 10.1.0.0 mask 255.255.255.0

This will generate an UPDATE message for  R2 to add  the network into its BGP table and if the network  is valid and best it will be added to the routing table. Note valid and best are indicated in the bgp table as  * valid, > best.


R2 BGP Table:
R2#sh ip bgp 
BGP table version is 4, local router ID is 2.2.2.2
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
*> 10.1.0.0/24      10.1.1.1                 0             0 100 i

R2 Routing Table:
R2#sh ip route 
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

172.17.0.0/24 is subnetted, 1 subnets
C       172.17.0.0 is directly connected, Loopback0
10.0.0.0/24 is subnetted, 2 subnets
C       10.1.1.0 is directly connected, Serial0/0
B       10.1.0.0 [20/0] via 10.1.1.1, 5d20h


Above in the bgp table snip shows R2 has learnt of the 10.1.0.0/24 network through BGP (B), and that it has come from AS 100 and that we have reachability through the next hop ip address of 10.1.1.1.

How let take a look at BGP the UPDATE and NOTIFICATION messages that took place I have captured the message types on the wireshark

 

Wednesday 29 October 2014

Basic Router ID in BGP


Hi all,

Having a router ID set is a good requirement for BGP not have this set the BGP process will select on for you the highest IP address of any loopback interface will be selected first and if none is found then the highest IP address of any physical interface.

R1
R1#sh ip bgp neighbors 
BGP neighbor is 10.1.1.2,  remote AS 200, external link
BGP version 4, remote router ID 172.17.0.1

R2
R2#sh ip bgp neighbors 
BGP neighbor is 10.1.1.1,  remote AS 100, external link
BGP version 4, remote router ID 10.1.0.1
BGP state = Established, up for 2d06h

We can control this selection with the “bgp router-id” command. Lets set our router id for R1 to 1.1.1.1 and R2 2.2.2.2.

R1
R1#config t
R1(config)#router bgp 100
R1(config-router)#bgp router-id 1.1.1.1
*Mar  8 02:54:27.985: %BGP-5-ADJCHANGE: neighbor 10.1.1.2 Down Router ID changed
*Mar  8 02:54:29.461: %BGP-5-ADJCHANGE: neighbor 10.1.1.2 Up 
R1(config-router)#

R2
R2#config t
R2(config)#router bgp 200
R2(config-router)#bgp router-id 2.2.2.2
*Mar 10 01:11:39.422: %BGP-5-ADJCHANGE: neighbor 10.1.1.1 Down Router ID changed
*Mar 10 01:11:42.178: %BGP-5-ADJCHANGE: neighbor 10.1.1.1 Up 
R2(config-router)#

Saturday 25 October 2014

Basic eBGP Peering


Hi all,

Studying for my CCIE RS, I would like to start of with BGP. On this post I am aiming to explain how BGP relationships form and at the message types with BGP messages.

Note: BGP connects autonomous system (AS) together



We are going to setup neighbour relationship between R1 in AS 100 and R2 in AS 200, Which will be our first eBGP relationship.

R1

config t
!
int lo0
ip address 10.1.0.1 255.255.255.0
!
int s0/2
ip address 10.1.1.1 255.255.255.0
no shut 
!
router bgp 100
neighbor 10.1.1.2 remote-as 200

R2

config t

int lo0
ip address 172.17.0.1 255.255.255.0
!
int s0/0
ip address 10.1.1.2 255.255.255.0
no shut
!
router bgp 200
neighbor 10.1.1.1 remote-as 100

So we have now created a BGP relationship in a few lines.

We can confirm that R1 and R2 are neighbors using the “sh ip bgp neighbors” command and below is the output from this

Looking closely at the output you will notices the relationship is an external one and secondly that the router ID advertised by R2 is 172.17.0.1, the BGP state is established and has been for 2 days and 5 hours and within the uptime period 6177 Keepalive messages. And lastly we can see that the connection is using port 179 on R2 and 57776 on R1 this indicates that R2 is the active peer of the relationship.

R1

R1#sh ip bgp neighbors 

BGP neighbor is 10.1.1.2,  remote AS 200, external link
  BGP version 4, remote router ID 172.17.0.1
  BGP state = Established, up for 2d05h
  Last read 00:00:30, last write 00:00:30, hold time is 180, keepalive interval is 60 seconds
  Neighbor capabilities:
    Route refresh: advertised and received(old & new)
    Address family IPv4 Unicast: advertised and received
  Message statistics:
    InQ depth is 0
    OutQ depth is 0
                         Sent       Rcvd
    Opens:                  4          4
    Notifications:          0          0
    Updates:                0          0
    Keepalives:          6177       6177
    Route Refresh:          0          0
    Total:               6181       6181
  Default minimum time between advertisement runs is 30 seconds

 #truncated#

Connection state is ESTAB, I/O status: 1, unread input bytes: 0            
Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 1
Local host: 10.1.1.1, Local port: 57776
Foreign host: 10.1.1.2, Foreign port: 179

R2

R2#sh ip bgp neighbors 

BGP neighbor is 10.1.1.1,  remote AS 100, external link
  BGP version 4, remote router ID 10.1.0.1
  BGP state = Established, up for 2d05h
  Last read 00:00:49, last write 00:00:49, hold time is 180, keepalive interval is 60 seconds
  Neighbor capabilities:
    Route refresh: advertised and received(old & new)
    Address family IPv4 Unicast: advertised and received
  Message statistics:
    InQ depth is 0
    OutQ depth is 0
                         Sent       Rcvd
    Opens:                  5          5
    Notifications:          0          0
    Updates:                0          2
    Keepalives:          6214       6212
    Route Refresh:          0          0
    Total:               6219       6219
  Default minimum time between advertisement runs is 30 seconds

   #truncated#

Connection state is ESTAB, I/O status: 1, unread input bytes: 0            
Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 1
Local host: 10.1.1.2, Local port: 179
Foreign host: 10.1.1.1, Foreign port: 57776

It's amazing to see how BGP completes it transformation to established, use the “debug bgp all” command is one way to accomplish another way is GNS3 by right clicking the link between R1 and R2 you can select capture which uses wire shark.

Below uses the Cisco IOS command the router goes through a number of states, from Active it goes to Idle, from it goes to Connect. From Connect it goes to Opensent, and then to OpenConfirm, before finally becoming Established.


ldle is the initial state when the routing process is enabled, or when the device is reset. The devices waits to receive a connection request from a remote peer, this is shown as the passive open message in the output below
Once we get the connection request we then move to Connect state this where the BGP process detects that a peer is attempting to connect and setup a TCP session.
The will then try to establish a TCP session with a peer. If the session is successful the connection state will move to Opensent state this is where the connection is established and an open messages is sent. The peer which receive the opensent confirms with an OpenComfirm massage state and a keep live message once received the peering transition to the Established state. At this point we can safely say that peering is now fully operational.

One more thing once we have established state the peer will exchange keepalives messages to make sure that the remote peer is still available the keepalive messages are sent by default 60 seconds and if no reply is heard within the hold time (default 180 seconds) the router declares the peer to be dead.


*Mar  7 18:14:52.607: BGP: 10.1.1.1 passive open to 10.1.1.2
*Mar  7 18:14:52.607: BGP: 10.1.1.1 went from Active to Idle
*Mar  7 18:14:52.607: BGP: 10.1.1.1 went from Idle to Connect
*Mar  7 18:14:52.611: BGP: 10.1.1.1 rcv message type 1, length (excl. header) 26
*Mar  7 18:14:52.611: BGP: 10.1.1.1 rcv OPEN, version 4, holdtime 180 seconds
*Mar  7 18:14:52.611: BGP: 10.1.1.1 went from Connect to OpenSent
*Mar  7 18:14:52.611: BGP: 10.1.1.1 sending OPEN, version 4, my as: 200, holdtime 180 seconds
*Mar  7 18:14:52.611: BGP: 10.1.1.1 rcv OPEN w/ OPTION parameter len: 16
*Mar  7 18:14:52.611: BGP: 10.1.1.1 rcvd OPEN w/ optional parameter type 2 (Capability) len 6
*Mar  7 18:14:52.611: BGP: 10.1.1.1 OPEN has CAPABILITY code: 1, length 4
*Mar  7 18:14:52.611: BGP: 10.1.1.1 OPEN has MP_EXT CAP for afi/safi: 1/1
*Mar  7 18:14:52.611: BGP: 10.1.1.1 rcvd OPEN w/ optional parameter type 2 (Capability) len 2
*Mar  7 18:14:52.611: BGP: 10.1.1.1 OPEN has CAPABILITY code: 128, length 0
*Mar  7 18:14:52.611: BGP: 10.1.1.1 OPEN has ROUTE-REFRESH capability(old) for all address-families
*Mar  7 18:14:52.611: BGP: 10.1.1.1 rcvd OPEN w/ optional parameter type 2 (Capability) len 2
*Mar  7 18:14:52.611: BGP: 10.1.1.1 OPEN has CAPABILITY code: 2, length 0
*Mar  7 18:14:52.611: BGP: 10.1.1.1 OPEN has ROUTE-REFRESH capability(new) for all address-families 
BGP: 10.1.1.1 rcvd OPEN w/ remote AS 100
*Mar  7 18:14:52.611: BGP: 10.1.1.1 went from OpenSent to OpenConfirm
*Mar  7 18:14:52.611: BGP: 10.1.1.1 send message type 1, length (incl. header) 45
*Mar  7 18:14:52.619: BGP: 10.1.1.1 went from OpenConfirm to Established
*Mar  7 18:14:52.623: %BGP-5-ADJCHANGE: neighbor 10.1.1.1 Up