jeff doyle and bgp fsm...

this gives me brain flotsam... jeff doyle had igor whiteboard this mess... sorry dr. frankenstein, but the absurdity of it will make us look smarter than them...

the above is for Will Hunting...  jeff,  that's a swing and a miss for the human's on the planet...


below, is for the outpatients...

you can follow this one... see the excellent link for more...

http://www.inetdaemon.com/tutorials/internet/ip/routing/bgp/operation/finite_state_model.shtml

R3# sh ip bgp neigh 1.1.1.1
BGP neighbor is 1.1.1.1,  remote AS 123, internal link
  BGP version 4, remote router ID 1.1.1.1
  BGP state = Established, up for 01:05:12

jeff nostradamus...

this according to doyle, routing tcpip,vol II pg 361...

...a Cisco router with IP routing disabled (no ip routing) and an ip default-gateway
command pointing to a locally attached interface. this setup enables you to use the IOS’s extensive debugging tools to observe network behavior from a host’s perspective.

i don't bother too much with qemu clients (hosts), other than olive's and asa's, because they are so resource intensive... the point of the above quote is that it presages the use of routers as pseudo clients by a few years as a quick an effective solution to put a client in gns3 for testing... i do the above and change the symbol to computer to avoid confusion...

quote of the day, doyle, bgp path attributes...

this gets it right, and is clear... thanks jeff...

Well-known attributes are either mandatory, meaning that they must be included in all BGP Update messages, or they are discretionary , meaning that they may or may not be sent in a specific Update message.
 
If an optional attribute is transitive , a BGP process should accept the path in which it is included, even if it doesn’t support the attribute, and it should pass the path on to its peers.

If an optional attribute is nontransitive , a BGP process that does not recognize the attribute can quietly ignore the Update in which it is included and not advertise the path to its other
peers.

quote of the day, according to doyle...

a distance vector protocol shares everything it knows, but only with directly connected neighbors. Link-state protocols announce information only about their directly connected links, but they share the information with all routers in their routing domain or area.

this is a very important distinction...

i always like going back to the fundamentals... as time goes by, they become even bigger...

bgp by doyle... part 2...

routing tcpip, chap 4, vol 2, part 2...

add r4, eigrp 1, the two loopbacks...

router eigrp 1
passive-interface Serial0
network 192.168.1.0
network 192.168.100.0
!
router bgp 200
redistribute eigrp 1
neighbor 192.168.1.226 remote-as 100

this is using redistribution which is not recommended for igp to bgp...

 r1#sh ip bgp
BGP table version is 9, local router ID is 1.1.1.1

     Network          Next Hop            Metric LocPrf Weight Path
 *>  192.168.1.216/30 192.168.1.225            0             0 200 ?
 r>  192.168.1.224/30 192.168.1.225            0             0 200 ?
 *>  192.168.100.0    192.168.1.225            0             0 200 ?
 *>  192.168.200.0    192.168.1.225       156160             0 200 ?
r1#

great... i always lke to study what is not recommended so i know to avoid it for the future... this practice of misconfiguring to prove a point i find is often confusing... this happens all the time...

so instead simply add the networks to bgp...

router bgp 200
network 192.168.1.216 mask 255.255.255.252
network 192.168.100.0
network 192.168.200.0
neighbor 192.168.1.226 remote-as 100

which means you are doing the work of the protocol... basically statically assigning the networks to bgp from eigrp... i guess my former colleague was right about bgp being static on steroids...

r1#sh ip bgp

BGP table version is 16, local router ID is 1.1.1.1

     Network          Next Hop            Metric LocPrf Weight Path

 *>  192.168.1.216/30 192.168.1.225            0             0 200 i

 *>  192.168.100.0    192.168.1.225            0             0 200 i

 *>  192.168.200.0    192.168.1.225       156160             0 200 i

note the use of the mask command for the eigrp link... the explanation is that it is a subnet, not a major network... this makes sense...

another big point is the lack of ? marks in the path output...  this is the origin indicator, whereas with redistribution it was incomplete, the i means that it originated from an igp...

so don't redistribute from igp to bgp, nor from bgp to igp... that's nice...

bgp by doyle...

chap 4, routing tcpip by doyle vol 2...

r1#sh run | begin router
router bgp 100
 bgp log-neighbor-changes
 neighbor 192.168.1.225 remote-as 200

r2#sh run | beg router
router bgp 200
 bgp log-neighbor-changes
 neighbor 192.168.1.226 remote-as 100

r2#
*Aug 24 18:05:23: %BGP-5-ADJCHANGE: neighbor 192.168.1.226 Up

r2#sh ip bgp neigh
BGP neighbor is 192.168.1.226,  remote AS 100, external link
  BGP version 4, remote router ID 192.168.1.226
  BGP state = Established, up for 00:03:32
  Last read 00:00:48, last write 00:00:52, hold time is 180, keepalive interval is 60 seconds
  Neighbor sessions:
    1 active, is not multisession capable (disabled)
  Neighbor capabilities:
    Route refresh: advertised and received(new)
    Four-octets ASN Capability: advertised and received
    Address family IPv4 Unicast: advertised and received
    Enhanced Refresh Capability: advertised and received
    Multisession Capability:
    Stateful switchover support enabled: NO for session 1
  Message statistics:
    InQ depth is 0
    OutQ depth is 0
   
                         Sent       Rcvd
    Opens:                  1          1
    Notifications:          0          0
    Updates:                1          1
    Keepalives:             5          5
    Route Refresh:          0          0
    Total:                  7          7
  Default minimum time between advertisement runs is 30 seconds

 For address family: IPv4 Unicast
  Session: 192.168.1.226
  BGP table version 1, neighbor version 1/0
  Output queue size : 0
  Index 2, Advertise bit 0
  2 update-group member
  Slow-peer detection is disabled
  Slow-peer split-update-group dynamic is disabled
                                 Sent       Rcvd
  Prefix activity:               ----       ----
    Prefixes Current:               0          0
    Prefixes Total:                 0          0
    Implicit Withdraw:              0          0
    Explicit Withdraw:              0          0
    Used as bestpath:             n/a          0
    Used as multipath:            n/a          0

                                   Outbound    Inbound
  Local Policy Denied Prefixes:    --------    -------
    Total:                                0          0
  Number of NLRIs in the update sent: max 0, min 0
  Last detected as dynamic slow peer: never
  Dynamic slow peer recovered: never
  Refresh Epoch: 1
  Last Sent Refresh Start-of-rib: never
  Last Sent Refresh End-of-rib: never
  Last Received Refresh Start-of-rib: never
  Last Received Refresh End-of-rib: never
                       Sent      Rcvd
    Refresh activity:           ----      ----
      Refresh Start-of-RIB          0          0
      Refresh End-of-RIB            0          0

  Address tracking is enabled, the RIB does have a route to 192.168.1.226
  Connections established 2; dropped 1
  Last reset 00:04:04, due to BGP Notification received, CEASE: unknown subcode
  Transport(tcp) path-mtu-discovery is enabled
  Graceful-Restart is disabled
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: 192.168.1.225, Local port: 60301
Foreign host: 192.168.1.226, Foreign port: 179
Connection tableid (VRF): 0

Enqueued packets for retransmit: 0, input: 0  mis-ordered: 0 (0 bytes)

Event Timers (current time is 0xE434C):
Timer          Starts    Wakeups            Next
Retrans             7          0             0x0
TimeWait            0          0             0x0
AckHold             6          4             0x0
SendWnd             0          0             0x0
KeepAlive           0          0             0x0
GiveUp              0          0             0x0
PmtuAger            1          0        0x142B74
DeadWait            0          0             0x0
Linger              0          0             0x0

iss: 4197193326  snduna: 4197193502  sndnxt: 4197193502     sndwnd:  16209
irs: 1924916453  rcvnxt: 1924916629  rcvwnd:      16209  delrcvwnd:    175

SRTT: 182 ms, RTTO: 1073 ms, RTV: 891 ms, KRTT: 0 ms
minRTT: 4 ms, maxRTT: 300 ms, ACK hold: 200 ms
Status Flags: none
Option Flags: higher precendence, nagle, path mtu capable

Datagrams (max data segment is 1460 bytes):
Rcvd: 12 (out of order: 0), with data: 7, total data bytes: 175
Sent: 13 (retransmit: 0 fastretransmit: 0),with data: 7, total data bytes: 175

the state, is it's finite state machine...
add another router with copper...

note in the below diagram the networks are 192.168.1.220/30 and 1.224/30.  the interface addresses are correct... i'm not fixing the diagram for that flaw... so there...

router bgp 100
neighbor 192.168.1.222 remote-as 100
neighbor 192.168.1.225 remote-as 200

notice the rid for r1...

r3#sh ip bgp neigh
BGP neighbor is 192.168.1.221,  remote AS 100, internal link
  BGP version 4, remote router ID 192.168.1.226
  BGP state = Established, up for 00:03:09

the neighbor is .221 but the rid is it's highest interface which happens to be connected to as200...

the rules for rid's are just like ospf... it'll choose the highest loopback, and without a loopback, it chooses the highest physical interface... using a loopback is preferred... for a discussion of this, go here:

http://defaultnetworking.blogspot.com/2012/05/advantages-of-loopback-interfaces-on.html

also, according to doyle...

Cisco’s BGP continues to use a router ID learned from a physical interface, even if the interface subsequently fails or is deleted. Therefore, the stability of a loopback interface is only a minor advantage. The primary benefit is the capability to control the router ID, making it easily distinguishable from other IP addresses.

add a loopback on r1...

r1(config)#interface loopback 0
r1(config-if)#ip address 192.168.255.254 255.255.255.255
r1(config-if)#end
r1#
*Aug 24 19:10:30: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback0, changed state to up
r1#
*Aug 24 19:10:31: %SYS-5-CONFIG_I: Configured from console by console
r1#clear ip bgp *
r1#
*Aug 24 19:10:48: %BGP-5-ADJCHANGE: neighbor 192.168.1.222 Down User reset
*Aug 24 19:10:48: %BGP_SESSION-5-ADJCHANGE: neighbor 192.168.1.222 IPv4 Unicast topology base removed from session  User reset
*Aug 24 19:10:48: %BGP-5-ADJCHANGE: neighbor 192.168.1.225 Down User reset
*Aug 24 19:10:48: %BGP_SESSION-5-ADJCHANGE: neighbor 192.168.1.225 IPv4 Unicast topology base removed from session  User reset
*Aug 24 19:10:48: %BGP-5-ADJCHANGE: neighbor 192.168.1.225 Up
*Aug 24 19:10:48: %BGP-5-ADJCHANGE: neighbor 192.168.1.222 Up

you have to clear bgp  for it to show up...

r3# sh ip bgp neigh
BGP neighbor is 192.168.1.221,  remote AS 100, internal link
  BGP version 4, remote router ID 192.168.255.254
  BGP state = Established, up for 00:01:21

but you knew that...

you can also set it manually using bgp router-id x.x.x.x

quote of the day, ospf...

according to doyle...

At a very high level, the operation of OSPF is easily explained:

1 OSPF-speaking routers send Hello packets out all OSPF-enabled interfaces. If two routers sharing a common data link agree on certain parameters specified in their respective Hello packets, they will become neighbors.

2 Adjacencies, which can be thought of as virtual point-to-point links, are formed
between some neighbors. OSPF defines several network types and several router types. The establishment of an adjacency is determined by the types of routers exchanging Hellos and the type of network over which the Hellos are exchanged.

3 Each router sends link-state advertisements (LSAs) over all adjacencies. The LSAs describe all of the router’s links, or interfaces, the router’s neighbors, and the state of the links. These links might be to stub networks (networks with no other router attached), to other OSPF routers, to networks in other areas, or to external networks (networks learned from another routing process). Because of the varying types of link-state information, OSPF defines multiple LSA types.

4 Each router receiving an LSA from a neighbor records the LSA in its link-state
database and sends a copy of the LSA to all of its other neighbors.

5 By flooding LSAs throughout an area, all routers will build identical link-state
databases.

6 When the databases are complete, each router uses the SPF algorithm to calculate a loop-free graph describing the shortest (lowest cost) path to every known destination, with itself as the root. This graph is the SPF tree.

7 Each router builds its route table from its SPF tree.



yeah, easy... have you memorized this yet?

quote of the day... delay...

according to doyle, routing tcpip vol1:

If a data link is thought of as a pipe, then bandwidth is the width of the pipe and delay is the length of the pipe. In other words, bandwidth is a measure of the carrying capacity, and delay is a measure of the end-to-end travel time.

quote of the day... distance vector...

distance vector... according to doyle...

routing tcpip vol1

of course you know this, but, so eloquent...

"The name distance vector is derived from the fact that routes are advertised as vectors of (distance, direction), where distance is defined in terms of a metric and direction is defined in terms of the next-hop router. For example, “Destination A is a distance of five hops away, in the direction of next-hop Router X.” As that statement implies, each router learns routes from its neighboring routers’ perspectives and then advertises the routes from its own perspective. Because each router depends on its neighbors for information, which the
neighbors in turn might have learned from their neighbors, and so on, distance vector routing is sometimes facetiously referred to as “routing by rumor.”"

split horizon  do not send updates out the same interface from which those routes were learned

consider everything you study as if for the first time...

quote of the day... according to doyle...

from routing tcpip, jeff doyle...

the data link/physical layers and the transport/network layers, as defined by the OSI model, perform very similar duties: They provide the means for conveying data from a source to a destination across some path. The difference is that the data link/physical layers provide communications across a physical path, whereas the transport/network layers provide communications across a logical or virtual path made up of a series of data links.