troubleshooting, from the horse's mouth...

there are a number of links that provide troubleshooting flow charts at cisco.com

eigrp
http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094613.shtml

ospf
http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a00800949f7.shtml

bgp
http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a008009478a.shtml

naturally, for just about any technology, you will find more of the same there...

bgp states...

the ccie is your super bowl... the ccie doesn't happen after the super bowl, or during the halftime show... the ccie doesn't get postponed by reruns of breaking bad or the latest zombie stupidity out there... the ccie is always there, taunting you, telling you you're not good enough... get pissed...

do you have these memorized? are they second nature? if this ever gets old  you will never be ccie...  does scott morris sleep? of course not... wake up...

do you know all of ospf's lsa's... the opaque's too...

router, network, network summary, summary asbr, external, nssa... that's 1,2,3,4,5 and 7... 6 is group or mospf, 8 is external, 9,10,11 are opaque, link-local scope, area local scope, AS scope

what are the eigrp packet types, there are 7?
hello, update, query, reply, ack, sia query, sia reply...
which ones require an ack? hint, it's not hello or ack...

ospf neighbor states:
down, attempt (nbma), init, two way, exstart, exchange, loading, full

ip packet header:
v,hl,diffserv,total length,identification,flags,frag offset,ttl,protocol, header checksum, sa,da,options,data

ospf network types:
broadcast, nbma, point-to-point, multipoint b'cast, and mpoint nbma

bgp attribute preference:
w,lp,local origination,as-path,origin code, lowest med, ebgp/ibgp, ibgp to bgp next hop, age, rid

ospf router types:
bb, internal, abr,asbr

ospf packets:
hello, dbd, lsr, lsu, lsa

ospf areas:
bb,standard, stub, totally stub, nssa, virtual link

what are you waiting for? get back to your lab...

here is a nice little write up from this guy...
 http://ipexptobe.blogspot.com/2011/09/bgp-neighbor-states_15.html

1. IDLE State :  veryfing route to neighbor

BGP refuses all incoming connections. No BGP resources are allocated in Idle state, and no incoming BGP connections are allowed.

2. Connect State : 

BGP waits for a TCP connection to be completed. If successful, the BGP state machine moves into OpenSent state after sending the OPEN message to the peer. Failure in this state could result in either going into Active state or Connect state, or reverting back to Idle state, depending on the failure reasons.

3. Active State : attempting connectivity to neighbor

In this state, a TCP connection is initiated to establish a BGP peer relationship. If successful, BGP sends its OPEN message to the peer and moves to OpenSent state. Failure can result in going to the Active or Idle states.

4. OpentSent State : open message sent to neighbor

After sending an OPEN message to the peer, BGP waits in this state for the OPEN reply.

If a successful reply comes in, the BGP state moves to OpenConfirm and a keepalive is sent to the peer. Failure can result in sending the BGP state back to Idle or Active.

5. OpenConfirm State : neighbor replied with open message

The BGP state machine is one step away from reaching its final state (Established).

BGP waits in this state for keepalives from the peer. If successful, the state moves to Established; otherwise, the state moves back to Idle based on the errors.

6. Established State : connection between neighbors established

This is the state in which BGP can exchange information between the peers. The information can be updates, keepalives, or notification.

quote of the day, karl solie...

just because it's old, doesn't mean it doesn't count... just weed out what's no longer useful... this from ccie practical studies volume 2...

go get em karl:

If the BGP peers are not able to reach each other using TCP port 179, you can use a number of TCP troubleshooting commands to troubleshoot the connection. As a best practice (that will save you many a headache), however, it is better to verify the router configuration for inaccuracies before troubleshooting a problem that might end up being a typo.

• Verify that the local BGP ASN is entered correctly.
• Verify that the remote peer's BGP ASN and IP address are entered correctly.
• Verify that the interfaces connecting the two peers are up and operational.
• If the peers are not directly connected, verify that they have a valid route (to and from) to reach each other.
• Check routers along the path between the peers for access lists or route policies that might be dropping or rerouting BGP traffic.
• Check logs for interface instabilities. Are routes flapping along the route between the BGP peers? Are any of the interfaces heavily congested or dropping packets? Keep in mind that BGP uses rather small packets for OPEN and KEEPALIVE messages. These packets are delayed if other larger packets are monopolizing a congested interface.
• If something has changed in the path between the two BGP peers, verify that it is not affecting the BGP session—for example, a new switch configuration, new access lists, a firewall, new routing policies, and so on.

Don't spend time troubleshooting BGP when it is not the problem! Establish a general layered troubleshooting methodology; it will be the number one troubleshooting tool and your best friend when you encounter a problem.

1. Layer 1

   - Check your cabling; verify that all cables are connected and that the interface is in a line up and protocol up state. Don't spend time troubleshooting BGP when you have a Layer 1 problem.

   - If you are using a serial link, make sure that you have set the correct clock rate. If you are using a channel service unit/data service unit (CSU/DSU), make sure it is properly configured and the line is up.

   - If you are using an Ethernet interface, make sure that the speed and duplex are set correctly on the router and switch.

   - Check the router and switch interfaces for errors; if there are errors, fix the error and then proceed with your troubleshooting. If you are using a Token Ring interface, make sure the router is configured to use the right ring speed, and that it has a good connection to the multistation access unit (MSAU) or switch.
   (note: I supported a 16mbps token ring network from '94 to '97)

2. Layer 2

   - If you are using an Ethernet connection, make sure that the switch port has been assigned to the proper VLAN.

   - Make sure that the VLAN is properly configured, and that there are no spanning-tree topology problems on the switch.

   - On an ATM interface, verify that the maximum transmission unit (MTU) is properly configured on both sides of the connection.

   - Verify that you are using the correct virtual path identifier/virtual channel identifier (VPI/VCI) pair, and that you have configured a valid ATM map for Layer 2 to Layer 3 connectivity. On a Frame Relay connection, verify that your local and remote data-link connection identifiers (DLCIs) and Local Management Interface (LMI) type are correctly set to match the values generated on the switch.

   - Verify that LMI is up and that the interface is not flapping.

   - If you are making a PPP connection, make sure PPP is configured on both sides of the connection.

   - Before proceeding to the next step, verify that your interface is not in a line up protocol down state.

3. Layer 3

   - Verify that you have configured the right IP address and subnet mask on the interface, check the other side of the connection, and verify that it is on the same subnet (if directly connected) or that it is what you think it is.

   - Make sure there is a valid route to reach your destination in the IP routing table. Trace the connection through any routers along the path, and verify that they have a path to and from each of the routers that they must reach for packets to reach your source and destination networks.

   - Check static routes for typos; make sure that any redistributed routes are actually being properly propagated.

   - If multiple paths are in use, verify that there are no routing loops.

   - If authentication is in use by any routing protocols, make sure that they are both using the correct passwords.

   - On nonbroadcast multiaccess (NBMA) networks, such as ATM or Frame Relay, make sure that you have proper support for Layer 2 to Layer 3 mappings, and that protocols such as Open Shortest Path First (OSPF) are configured for the proper network type.

   - Before proceeding to the next step, verify that you are able to reach the destination network from the source network and vice versa.

4. Layer 4

   - Check for any access lists or firewalls that might be dropping TCP packets.

   - Verify that you have connectivity on TCP port 179. One BGP speaker, the passive TCP host, will receive a TCP request on port 179, and the other speaker, the active TCP host, will use a random TCP source port (beginning at 11,000) to initiate the TCP session.

   - Check for retransmissions, out-of-order packets, or other TCP symptoms that might be pointing to network congestion or invalid configurations.

After verifying that all the prior conditions are not affecting the BGP session, use TCP show and debug commands to help narrow down the culprit.

TCP Command	Command Description
show tcp	This command displays detailed information on each TCP session that the local router has formed with a remote peer. It can be used with BGP to show whether the local and remote BGP peers have formed an established TCP session, and show details about that session.
show tcp [brief][all] [| include 179]	This command displays a brief status of each of the TCP sessions that the local router has formed with a remote router. This is a basic summary command that you can use as another tool to verify the BGP TCP connection between peers.
debug ip tcp transactions	This command, which should be used with caution on a production router, displays information about TCP session changes. It enables you to troubleshoot a BGP TCP session, displaying information about TCP retransmissions or state changes.
debug ip tcp packet [in | out | address IP-address | port port-number]	This command displays detailed information about TCP packets. It can be used with the in, out, address, or port arguments to specify particular traffic, and must be used with extreme caution on a production router. With this command, you can monitor TCP packets sent and received by the local router. This information enables you to determine the cause of an unstable BGP TCP session and resolve route flapping or general connectivity issues.

If the show tcp command output for the peer IP address used for the BGP session is anything other than ESTAB, troubleshoot the TCP connection.

halabi bgp cont...

it's paint by numbers...

rtc(config)#router bgp 1
rtc(config-router)#neigh 172.16.20.2 remote-as 3
rtc(config-router)#
*Jan 30 11:58:39: %BGP-5-ADJCHANGE: neighbor 172.16.20.2 Up
rtc(config-router)#end
rtc#
*Jan 30 11:58:51: %SYS-5-CONFIG_I: Configured from console by console
rtc#sh tcp brie all
TCB       Local Address               Foreign Address             (state)
67F17354  172.16.20.1.179             172.16.20.2.63717            ESTAB
68636BC8  0.0.0.0.179                 172.16.20.2.*                LISTEN

i do love that show tcp brief all command...

i hate when i'm an idiot, but i'm used to it... he gives no config for rte, he just states in the topology that it doesn't have bgp...

here is the rtd config:

rtd#sh run | b router
router ospf 10
 network 192.68.0.0 0.0.255.255 area 0
!
router bgp 2
 bgp log-neighbor-changes
 neighbor 192.68.5.1 remote-as 3
 neighbor 192.68.5.1 ebgp-multihop 2

so i configured rte thus...

rte#sh run int s1/0
Building configuration...

Current configuration : 88 bytes
!
interface Serial1/0
 ip address 192.68.5.2 255.255.255.0
 serial restart-delay 0
end

rte#sh run int s1/1
Building configuration...

Current configuration : 89 bytes
!
interface Serial1/1
 ip address 192.68.12.2 255.255.255.0
 serial restart-delay 0
end

rte#sh run | b router
router ospf 1
 network 192.68.0.0 0.0.255.255 area 0

this is shalabi's output... look closely...

RTF#show ip bgp neighbor
 BGP neighbor is 172.16.2.254, remote AS 3, internal link
 BGP version 4, remote router ID 172.16.2.254
 BGP state = Established, table version = 2, up for 22:36:09

 BGP neighbor is 192.68.12.1, remote AS 2, external link
 BGP version 4, remote router ID 192.68.5.2
 BGP state = Established, table version = 2, up for 22:13:01

not sure how that can be... he explicitly states that rte is not running bgp... 192.68.5.2 is the other side of rtf's serial connection... i stand by my configuration...

rtf#sh ip bgp neigh | i BGP
BGP neighbor is 172.16.2.254,  remote AS 3, internal link
  BGP version 4, remote router ID 172.16.2.254
  BGP state = Established, up for 00:43:01
  BGP table version 1, neighbor version 1/0
 
BGP neighbor is 192.68.12.1,  remote AS 2, external link
  BGP version 4, remote router ID 192.68.12.1
  BGP state = Established, up for 00:10:12
  BGP table version 1, neighbor version 1/0
  Last reset 00:12:29, due to BGP protocol initialization
  External BGP neighbor may be up to 2 hops away.

somebody's lying to somebody here...

then he writes:

RTF's other neighbor 192.68.12.1 is also in an established state. This external neighbor belongs to AS2. Note that the display indicates that this neighbor is two hops away (as configured in the ebgp-multihop).

which confirms my configuration...

bgp origin...

routes that were learned via redistribution will give you an origin code of ? or incomplete... learned from a source other than igp...

routes learned through an igp will give you an origin code of "i" as below... these things we know...

isp#sh ip bgp | b Network
     Network          Next Hop            Metric LocPrf Weight Path
 *   172.16.0.0       192.168.1.6              0             0 64512 i
 *>                   192.168.1.2              0             0 64512 i
 *>  192.168.1.0/30   0.0.0.0                  0         32768 i
 *>  192.168.1.4/30   0.0.0.0                  0         32768 i
 *>  192.168.100.0    0.0.0.0                  0         32768 i

look ma, no routes learned through redistribution...

if you receive routes with an origin code of "e" then immediately check yourself into the EGP mental ward because you're seeing things...

however, a redistributed route that has been defined as a network in bgp, ie, network 10.1.1.0 mask 255.255.255.0, will still have as it's origin "i", not "?", even though it has been redistributed...

lay it on them habibi:

Although network X has been injected into BGP via explicit redistribution of static routes, it is also defined natively to BGP via the network command, which is why it is sent out with an ORIGIN of IGP(i). If network X had not been defined with a static network command, it would have been sent out with an ORIGIN of INCOMPLETE. It should be noted that network X did not need to be redistributed because defining it statically and listing it via the network command would suffice to inject it into BGP.

bgp capabilities...

have at it... as if there wasn't enough already... this is borderline trivia...

https://tools.ietf.org/html/rfc5492

This specification defines an Optional Parameter and processing rules
   that allow BGP speakers to communicate capabilities in an OPEN
   message.  A pair of BGP speakers that supports this specification can
   establish the peering even when presented with unrecognized
   capabilities, so long as all capabilities required to support the
   peering are supported.

which means they're not a peer breaker...

note: route refresh appears as a capability in an open message, but it is also a message, type 5...

open, update, notification, keepalive and route refresh. in numerical order by type...

bgp update...

as-path, origin and next hop are well known transitive... it has to be true, it says so right in the update packet...

bgp messages...

nothing groundbreaking here...

1 open, 2 update, 3 notification 4 keepalive... and 5 route refresh (introduced in 2000, after halabi went to the presses:

 http://tools.ietf.org/html/rfc2918

null0 default bgp...

the following example is from r2 in the last tshoot lab 10...  the routing is static... pay particular attention to the default route, and the advertised network in bgp... r2 below in the lab represents the isp:

R2#sh run | b router
router bgp 65502
 no synchronization
 bgp log-neighbor-changes
 network 0.0.0.0
 neighbor 192.168.1.1 remote-as 65501
 neighbor 192.168.1.1 ebgp-multihop 2
 neighbor 192.168.1.1 update-source Loopback0
 no auto-summary!
ip route 0.0.0.0 0.0.0.0 Null0
ip route 10.1.0.0 255.255.0.0 209.165.200.225
ip route 192.168.1.1 255.255.255.255 209.165.200.225

on r1, the customer (enterprise), all 0's is the advertised bgp network... 10.1.0.0 is the internal enterprise network... r1's 192.168.1.1 is connected to 192.168.2.1...

R1#sh tcp brie all
TCB       Local Address           Foreign Address        (state)
84D5CF00  192.168.1.1.32348       192.168.2.1.179        ESTAB


R1#sh ip bgp | b Network
   Network          Next Hop            Metric LocPrf Weight Path
*> 0.0.0.0          192.168.2.1              0             0 65502 i

the effectiveness of the default to null0 in conjunction with the statics is clearly shown here... of course within the confines of the lab it is meaningless but we have our imagination hats on, correct? 

from doyle:

Configuring a Default Route to BGP Neighbors
router bgp 100
network 0.0.0.0
neighbor 192.168.1.210 remote-as 300
neighbor 192.168.1.222 remote-as 100
neighbor 192.168.1.225 remote-as 200
!
ip route 0.0.0.0 0.0.0.0 Null0
 
A default route to the Null0 interface is created statically, and the route is advertised with the network command...

 any destination address that cannot be matched to a more-specific route matches the static route and is dropped.

from halabi:

Less-Specific Routes of a Network’s Own Aggregate

A specific rule of routing states that, for the sake of preventing routing loops, a network must not follow a less-specific route for a destination that matches one of its own aggregated routes. A routing loop occurs when traffic circles back and forth between network elements, never reaching its final destination. Default routes 0.0.0.0/0 are a special case of this rule. A network should not follow the default route to reach destinations that are part of its aggregated advertisements. This is why routing protocols that handle aggregation of routes should always keep a bit bucket (Null0 route in Cisco parlance) to the aggregate route itself. Traffic sent to the bit bucket will be discarded, which prevents
potential looping situations.

this is wildly important...

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

quote of the day... netcerts.net...

bgp... live it, breathe it, hate it...

http://netcerts.net/bgp-path-attributes-and-the-decision-process/

this guy, amit, belongs in your bookmarks... bookmark him NOW...

a BGP Speaker will add its AS number to the AS_Path only when an Update message is being sent to the neighbor which means only when BGP is advertising the route to the peer it will prepend its AS number to the AS_Path attribute.

repetition makes the heart grow fonder... arghh... of course there are a million little rules for bgp because you have to do everything for it... it should be called a no-routing protocol... 

it's articles like his that speak to how far you have to go... the never ending story...

bgp added to tshoot...

the bgp configuration...

R1#ping 209.65.200.241
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 209.65.200.241, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/32/44 ms

the server 209.65.200.241 is simply a default route...

209.65.200.241#sh run | begin route
ip route 0.0.0.0 0.0.0.0 209.65.200.242

bgp65002#sh run | b router
router bgp 65002
 bgp log-neighbor-changes
 network 209.65.200.224 mask 255.255.255.252
 network 209.65.200.240 mask 255.255.255.248
 neighbor 209.65.200.225 remote-as 65001

R1#sh run | b router
router ospf 1
 redistribute bgp 65001 subnets
 network 1.1.1.0 0.0.0.255 area 12
 network 10.1.1.0 0.0.0.3 area 12
!
router bgp 65001
 bgp log-neighbor-changes
 network 209.65.200.224 mask 255.255.255.252
 neighbor 209.65.200.226 remote-as 65002

next we'll need translation on r1...

R1#sh run | inc nat
 ip nat inside (on s1/0.12)
 ip nat outside (on s1/2)
 
ip nat pool cisco 209.65.200.225 209.65.200.225 netmask 255.255.255.252
ip nat inside source list 1 pool cisco overload
 
R1#sh access-list
Standard IP access list 1
    10 permit 10.1.1.0, wildcard bits 0.0.0.255 (5 matches)

R4#ping 209.65.200.241
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 209.65.200.241, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 72/90/112 ms

R1#
*Jan  3 18:53:01.030: NAT*: ICMP id=1024->0
*Jan  3 18:53:01.030: NAT*: s=209.65.200.241, d=209.65.200.225->10.1.1.10 [2]
*Jan  3 18:53:01.110: NAT*: ICMP id=0->1024
*Jan  3 18:53:01.110: NAT*: s=10.1.1.10->209.65.200.225, d=209.65.200.241 [3]
*Jan  3 18:53:01.130: NAT*: ICMP id=1024->0
*Jan  3 18:53:01.130: NAT*: s=209.65.200.241, d=209.65.200.225->10.1.1.10 [3]
*Jan  3 18:53:01.194: NAT*: ICMP id=0->1024
*Jan  3 18:53:01.194: NAT*: s=10.1.1.10->209.65.200.225, d=209.65.200.241 [4]
*Jan  3 18:53:01.218: NAT*: ICMP id=1024->0
*Jan  3 18:53:01.218: NAT*: s=209.65.200.241, d=209.65.200.225->10.1.1.10 [4]
R1#sh ip nat trans
Pro Inside global      Inside local       Outside local      Outside global
icmp 209.65.200.225:1024 10.1.1.10:0  209.65.200.241:0  209.65.200.241:1024        

still a ways to go... dhcp on r4 to the switched network should be fun across the qinq... some vlans, port channels... then after, ipv6 all over the place and the tunnel...

damn...

 R4#sh ip route | b Gate
Gateway of last resort is not set

      1.0.0.0/24 is subnetted, 1 subnets
O IA     1.1.1.0 [110/193] via 10.1.1.9, 04:08:47, Serial1/0.34
      2.0.0.0/24 is subnetted, 1 subnets
O IA     2.2.2.0 [110/129] via 10.1.1.9, 04:08:47, Serial1/0.34
      3.0.0.0/24 is subnetted, 1 subnets
O        3.3.3.0 [110/65] via 10.1.1.9, 04:08:50, Serial1/0.34
      4.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        4.4.4.0/24 is directly connected, Loopback0
L        4.4.4.4/32 is directly connected, Loopback0
      10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
O IA     10.1.1.0/30 [110/192] via 10.1.1.9, 04:08:47, Serial1/0.34
O IA     10.1.1.4/30 [110/128] via 10.1.1.9, 04:08:47, Serial1/0.34
C        10.1.1.8/30 is directly connected, Serial1/0.34
L        10.1.1.10/32 is directly connected, Serial1/0.34
      209.65.200.0/24 is variably subnetted, 2 subnets, 2 masks
O E2     209.65.200.224/30 [110/1] via 10.1.1.9, 00:52:43, Serial1/0.34
O E2     209.65.200.240/29 [110/1] via 10.1.1.9, 00:49:46, Serial1/0.34

bgp prefers ebgp...

that seems counterintuitive...

at first blush one would think the opposite is true...

arteq, you say, forsooth...

but soft reconfiguration, what light through yonder window breaks...

the answer is staring you in the face...

it is a question of believability...

from the mouth of madness: http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094823.shtml

Administrative distance - This is the measure of trustworthiness of the source of the route. If a router learns about a destination from more than one routing protocol, administrative distance is compared and the preference is given to the routes with lower administrative distance. In other words, it is the believability of the source of the route.

don't look at me; i didn't make this shit up...

quote of the day... kevin wallace...

kevin wallace on bgp preference...

nothing new here, but always good to review...

1. BGP prefers the path with the highest weight. Note that the BGP weight parameter is a Cisco-specific parameter.

2. BGP prefers the path with the highest local preference value.

3. BGP prefers the path originated by BGP on the local router.

4. BGP prefers the path with the shortest autonomous system.

5. BGP prefers the path with the lowest origin type. (NOTE: IGP < EGP
  < INCOMPLETE.)

6. BGP prefers the path with the lowest multi-exit discriminator (MED).

7. BGP prefers eBGP paths over iBGP paths.

8. BGP prefers the path with the lowest IGP metric to the BGP next-hop.

9. BGP prefers the path that points to a BGP router with the lowest BGP router ID.

bgp synchro historically...

the why?

from here: http://www.cisco.com/en/US/docs/ios/12_3/iproute/command/reference/ip2_s3g.html#wp1041409

synchronization

To enable the synchronization between BGP and your Interior Gateway Protocol (IGP) system, use the synchronization command in address family or router configuration mode. To enable the Cisco IOS software to advertise a network route without waiting for the IGP, use the no form of this command.

synchronization

no synchronization

Command History

Release	Modification
10.0	This command was introduced.
12.0(7)T	Address family configuration mode was added.
12.2(8)T	Command default behavior changed to disabled.

Usage Guidelines

Usually, a BGP speaker does not advertise a route to an external neighbor unless that route is local or exists in the IGP. By default, synchronization between BGP and the IGP is turned off to allow the Cisco IOS software to advertise a network route without waiting for route validation from the IGP. This feature allows routers and access servers within an autonomous system to have the route before BGP makes it available to other autonomous systems.

Use the synchronization command if routers in the autonomous system do not speak BGP.

and from yap:


 http://www.itcertnotes.com/2012/01/bgp-synchronization.html

The BGP synchronization rule states that a BGP router cannot use an IBGP-learned transit route nor advertise it to an EBGP peer; unless it is synchronized in both BGP and IGP routing tables – IGP has redistributed and propagated it across the AS and installed it in the local IP routing table. BGP running in a transit AS that is passing traffic between ASes should not advertise a route before all routers in the AS have learned about the route via IGP. The BGP synchronization rule ensures consistency information throughout an AS to avoid routing black holes within the AS, eg: advertising a destination to an EBGP neighbor when not all routers within the AS can route to the destination.

BGP synchronization should only be used when there are routers in the AS that do not run BGP. It is safe to disable BGP synchronization only if all routers in the transit path in the AS – the path between the BGP border routers, are running BGP; or when the AS is not a transit AS. BGP synchronization is enabled by default in earlier version of Cisco IOS releases. Most current Cisco IOS releases (Cisco IOS Release 12.2(8)T and later) has disabled BGP synchronization by default, as most ISPs run BGP on all routers within their ASes.


and this from:
 http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CDQQFjAA&url=http%3A%2F%2Fwww.cisco.com%2Fimage%2Fgif%2Fpaws%2F13753%2F25.pdf&ei=ZTLaUJDuHbC70QGH5oGoBg&usg=AFQjCNFedx4tm6q2qoiGrJaayKP43xsE_Q&sig2=x_0yP-0qBR0zaP-0HXQUvw

 Why Routers Ignore Paths

Assume that all paths that a router receives for a particular prefix are arranged in a list. The list is similar to
the output of the show ip bgp longer−prefixes command. In this case, some paths are not considered as
candidates for the best path. Such paths typically do not have the valid flag in the output of the show ip bgp
longer−prefixes command. Routers ignore paths in these circumstances:

• Paths that are marked as not synchronized in the show ip bgp longer−prefixes output

If BGP synchronization is enabled, there must be a match for the prefix in the IP routing table in order for an internal BGP (iBGP) path to be considered a valid path. BGP synchronization is enabled by
default in Cisco IOS® Software. If the matching route is learned from an Open Shortest Path First (OSPF) neighbor, its OSPF router ID must match the BGP router ID of the iBGP neighbor. Most users prefer to disable synchronization with use of the no synchronization BGP subcommand.

Note: Synchronization is disabled by default in Cisco IOS Software Release 12.2(8)T and later.

• Paths for which the NEXT_HOP is inaccessible
Be sure that there is an Interior Gateway Protocol (IGP) route to the NEXT_HOP that is associated with the path.

more bgp synchro...

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

BGP is an exterior gateway protocol, which means it does not keep track of routing within it's own AS. For BGP to work properly, you must be running an interior gateway protocol such as RIP, IGRP, OSPF, IS-IS or EIGRP.
A Cisco router running BGP will not advertise a route unless the route appears in the IP routing table and there is a network statement authorizing BGP to advertise the route.
While a network administrator can configure a network statement at any time, this will not guarantee the advertisement of the route. A route to an interior host will not appear in the IP table until it has been selected by an interior protocol as the best route and inserted in the IP routing table. Once the internal route appears, BGP and the interior routing protocol are said to be 'synchronized'.
This is necessary to prevent routing loops. A BGP speaking router will only advertise it's own routes, and will not announce any of it's iBGP neighbor's routes to any other iBGP peer. BGP does this to prevent routing loops within the AS.

not bad...

http://docwiki.cisco.com/wiki/Internetworking_Case_Studies_--_Using_the_Border_Gateway_Protocol_for_Interdomain_Routing#Synchronization

http://www.nnk.com.au/index.php?option=com_content&view=article&id=22:bgp-synchronization&catid=3:articles&Itemid=5

pause for station identification...

let's hope narbik doesn't mind the free publicity...

R5#sh ip bgp
R5#

When redistributing between OSPF and BGP, we should review BGP’s synchronization rule which states:

An IBGP learned prefix will not be advertised to another BGP speaker unless that same prefix resides in the IBGP speaker’s local IGP table.

Basically this rule was set to stop blackholing routes. This rule is well defined in RFC 1745 and it possesses another requirement, and that’s when OSPF is the IGP used within the AS. This rule does not apply if the IGP is NOT OSPF.

This RFC states that if OSPF is used as the IGP in the AS, the router ids of OSPF and BGP on the border router, which is the router that performs the redistribution of BGP into OSPF must be the same.

to wit:

R2#sh run | b router
router ospf 1
 router-id 0.0.0.2
 redistribute bgp 234 subnets
 network 10.1.23.0 0.0.0.255 area 0
!
router bgp 234
 synchronization
 bgp router-id 2.2.2.2
 bgp log-neighbor-changes
 neighbor 10.1.12.1 remote-as 100
 neighbor 10.1.23.3 remote-as 234
 neighbor 10.1.23.3 next-hop-self
 neighbor 10.1.34.4 remote-as 234
 neighbor 10.1.34.4 next-hop-self

not so fast with the router id's...

first:

R3#sh ip bgp | b Net
     Network          Next Hop            Metric LocPrf Weight Path
 * i 1.0.0.0          10.1.23.2                0    100      0 100 i

good... now match the id's and clear bgp and ospf on r2...

R2#sh run | b router
router ospf 1
 router-id 2.2.2.2
 redistribute bgp 234 subnets
 network 10.1.23.0 0.0.0.255 area 0
!
router bgp 234
 synchronization
 bgp router-id 2.2.2.2

and this is what we accomplished... a rib failure...

R3#sh ip bgp | b Net
     Network          Next Hop            Metric LocPrf Weight Path
 r>i 1.0.0.0          10.1.23.2                0    100      0 100 i

and it's what we wanted...

R3#sh ip bgp rib-fa
  Network            Next Hop                      RIB-failure   RIB-NH Matches
1.0.0.0            10.1.23.2           Higher admin distance              n/a

although a route now exists in r5 to 1.0.0.0 there is no way back...

R5#sh ip route bgp | b Gate
Gateway of last resort is not set

B     1.0.0.0/8 [20/0] via 10.1.45.4, 08:33:40

r1 is still not in the game...

R1#sh ip route ospf
R1#

R2

router bgp 234
  neighbor 10.1.12.1 default-originate

and R4

R4(config)#router ospf 1
R4(config-router)#netw 10.1.45.4 0.0.0.255 area 0

solves the dilemma...

R1#sh ip route | b Gate
Gateway of last resort is 10.1.12.2 to network 0.0.0.0

B*    0.0.0.0/0 [20/0] via 10.1.12.2, 00:04:19

R5#ping 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 48/66/76 ms

narbik sync...

narbik is on the sync...

it's like the guy read my mind... i have never been satisfied with anyone's explanation of this shit...

whaddya mean you haven't downloaded it yet... hulk smash...

http://micronics.nl/BGP-Syn.pdf http://micronics.nl/BGP-Syn.pdf

tell me you love my ellipses... go ahead... who's your pal, who's your buddy...

up to the bgp verifications, and task 4...

R2#sh ip bgp summ | b Neighbor
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.1.12.1       4          100      27      26        2    0    0 00:20:34        1
10.1.23.3       4          234      22      23        2    0    0 00:16:25        0
10.1.34.4       4          234      20      22        2    0    0 00:15:06        0

R3#sh ip bgp summ | b Nei
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.1.23.2       4          234      23      23        1    0    0 00:17:13        1
10.1.34.4       4          234      19      18        1    0    0 00:15:31        0

R3#sh ip bgp | b Netw   
     Network          Next Hop            Metric LocPrf Weight Path
 * i 1.0.0.0          10.1.23.2                0    100      0 100 i

R4#sh ip bgp summ | b Nei
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.1.23.2       4          234      24      22        1    0    0 00:16:36        1
10.1.34.3       4          234      19      20        1    0    0 00:16:13        0

include r4 and r5...

just follow the bouncing narbik...

R4#sh ip bgp summ | b Neigh
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.1.23.2       4          234      31      29        1    0    0 00:23:06        1
10.1.34.3       4          234      26      27        1    0    0 00:22:44        0
10.1.45.5       4          500       0       0        1    0    0 never    Idle

R5#sh ip bgp summ | be Nei
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.1.45.4       4          234       0       0        1    0    0 never    Idle

task 5 redist bgp on r2...

R2(config)#router ospf 1
R2(config-router)#redist bgp 234 subn
R2(config-router)#end

verify on r3...

R3#sh ip route ospf | b Gate
Gateway of last resort is not set

O E2  1.0.0.0/8 [110/1] via 10.1.23.2, 00:02:48, FastEthernet0/1
 
R3#sh ip bgp | b Net
     Network          Next Hop            Metric LocPrf Weight Path
 * i 1.0.0.0          10.1.23.2                0    100      0 100 i
R3#

just like new york...

R4#sh ip bgp | b Net
     Network          Next Hop            Metric LocPrf Weight Path
 * i 1.0.0.0          10.1.23.2                0    100      0 100 i
R4#ping 10.1.23.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.23.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/37/56 ms

this is the upshot...  reachability but no best route...

R4#sh ip bgp 1.0.0.0
BGP routing table entry for 1.0.0.0/8, version 0
Paths: (1 available, no best path)
  Not advertised to any peer
  Refresh Epoch 2
  100
    10.1.23.2 (metric 2) from 10.1.23.2 (2.2.2.2)
      Origin IGP, metric 0, localpref 100, valid, internal, not synchronized
      rx pathid: 0, tx pathid: 0

reason number 2013...

...that you should be digging into the cisco learning network... besides the fact i've posted many articles and downloadables there under my profile...

narbik on bgp synchronization, from the link below:

a downloadable pdf from the man, the myth...


http://micronics.nl/BGP-Syn.pdf http://micronics.nl/BGP-Syn.pdf

you can set up an account and receive automatic email notifications from the groups you belong to, on topics that interest you, because we live in the age of information transfer and shit...

this has been a public service announcement...

a mind is a terrible thing...

bgp preferences...

it's kinda like a woman... size matters in the early stages...

1. weight (bigger)
2. local preference (bigger)
3. locally originated

one moment here...  this means THIS router generated it...

the rest are smaller, or littler, or older or more shriveled...

4. as-path (lowest)
5. origin

meaning code or type... i before e and question mark last... however, there are no e's (external gateway protocol) anymore... ? means learned through redistribution...

6. med (lowest)

multi-exit discriminator means just the opposite for the local router; the paths coming into, not out of... i hate that shit...


how cisco puts it...

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094934.shtml

MED is an optional nontransitive attribute. MED is a hint to external neighbors about the preferred path into an autonomous system (AS) that has multiple entry points. The MED is also known as the external metric of a route. A lower MED value is preferred over a higher value.

7. external, or EBGP over IBGP
8. IGP cost (smaller)
9. EBGP Peering (age; older)
10. RID (lower)


synchronization side note...

from cisco wiki:

 http://docwiki.cisco.com/wiki/Internetworking_Case_Studies_--_Using_the_Border_Gateway_Protocol_for_Interdomain_Routing#Synchronization

Synchronization

When an AS provides transit service to other ASs and if there are non-BGP routers in the AS, transit traffic might be dropped if the intermediate non-BGP routers have not learned routes for that traffic via an IGP. The BGP synchronization rule states that if an AS provides transit service to another AS, BGP should not advertise a route until all of the routers within the AS have learned about the route via an IGP.