Tag Archives: 3.7b

3.7.b Implement and troubleshoot IBGP and EBGP

3.7.b [i] EBGP, IBGP

here is an older site (2008) devoted to bgp review… it is based on some old school cisco.com graphics (which i actually like a lot, similar to this one for ospf which is outstanding: http://www.cisco.com/en/US/tech/tk365/technologies_white_paper09186a0080094e9e.shtml

http://bgpconcepts.blogspot.com/2008/11/how-does-bgp-work.html

and the bgp case studies tech notes on cisco.com here:

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

3.7.b Implement and troubleshoot IBGP and EBGP

3.7.b [i] EBGP, IBGP

the conventional wisdom for directly connected EBGP routers when using loopbacks as the update source is to manually set the ebgp-multihop to a number greater than 1 in order to establish the peering… this manually sets the ttl value  as seen below to a number other than the default…

bgp_ttl_mhop

the disable-connected-check accomplishes the same thing without changing the ttl value…

bgp_disable_connect_cap

according to cisco here: http://www.cisco.com/en/US/docs/ios/iproute_bgp/command/reference/irg_bgp3.html#wp1106122

disable connected check

A BGP routing process will verify the connection of single-hop eBGP peering session (TTL=254) to determine if the eBGP peer is directly connected to the same network segment by default. If the peer is not directly connected to same network segment, connection verification will prevent the peering session from being established.

neighbor ebgp-multihop

To accept and attempt BGP connections to external peers residing on networks that are not directly connected, use the neighbor ebgp-multihop command in router configuration mode. To return to the default, use the no form of this command.

they accomplish the same thing…

this guy here has more on it:

http://lostintransit.se/tag/disable-connected-check/

3.7.b Implement and troubleshoot IBGP and EBGP

3.7.b [i] EBGP, IBGP

from wendell, r&s

The BGP network router subcommand differs significantly from the network command used by
IGPs. The BGP network command instructs that router’s BGP process to do the following:
Look for a route in the router’s current IP routing table that exactly matches the
parameters of the network command; if the IP route exists, put the equivalent NLRI into
the local BGP table.
With this logic, connected routes, static routes, or IGP routes could be taken from the IP routing
table and placed into the BGP table for later advertisement. When the router removes that route
from its IP routing table, BGP then removes the NLRI from the BGP table, and notifies neighbors
that the route has been withdrawn.
Note that the IP route must be matched exactly when the no auto-summary command is
configured or used by default.

the withdrawn route is part of an update… see bgp update below…

3.7.b Implement and troubleshoot IBGP and EBGP

3.7.b [i] EBGP, IBGP

from:

http://blog.ipexpert.com/2009/01/05/external-bgp-links-and-next-hop-self/

Generally speaking, for EBGP peering using the BGP standards, we peer based on the IP address of the BGP neighbors’ local interfaces. However, that brings up some challenging permutations. When peering is done via the external network of a BGP edge router within an AS, a BGP edge router will not change the next hop of for the route from the advertising AS when it receives it but rather will pass it on unchanged to its IBGP neighbors.

If the external network connecting the two AS’s is not advertised into the IGP of the receiving AS, the next hop of the route will presumably be unreachable.

So this presents us with a few options…

  1. We can redistribute the external network into the IGP.
  2. We can advertise the external network into the IGP (presumably as a passive interface).
  3. We can configure the next hop self parameter on the edge router on the receiving AS’s internal neighbor relationships.

Being aware of all three methods is important to understanding the options available to you should you need to configure “RFC-compliant” BGP. My personal preference is setting the next-hop-self parameter on each of the edge router’s IBGP connections, thus ensuring a reachable next hop without increasing the size of the IGP table. It is not necessarily going to maintain the most optimal routing path to exit the AS (due to the default BGP path selection process being inferior to that of an IGP) but it consistently works to establish connectivity.

3.7.b Implement and troubleshoot IBGP and EBGP

3.7.b [i] EBGP, IBGP

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

Because there is no component route (no classful route or subnet route ) in the R101 IP routing table, the network 6.0.0.0 in not installed in the BGP table. The minimum requirement for a prefix configured under the network command to be installed in a BGP table is to have a component route in the IP routing table. So make sure that R101 has a component route for network 6.0.0.0/8 either by learning it through IGP or through static configuration

null0 can be used to advertise a route in bgp when the so called component route is missing, or the component route is advertised by the igp and null0 will not be necessary… in english please… can you hear me in the back…

note the mask on the interface and then note the mask in bgp for 10.1.1.1

R1#sh run int lo1
Building configuration…

Current configuration : 94 bytes
!
interface Loopback1
ip address 10.1.1.1 255.255.255.0
ip ospf network point-to-point

router bgp 65001
bgp log-neighbor-changes
network 10.1.0.0 mask 255.255.0.0

that dog don’t hunt… look at the route table…

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

1.0.0.0/32 is subnetted, 1 subnets
C        1.1.1.1 is directly connected, Loopback0
2.0.0.0/32 is subnetted, 1 subnets
O        2.2.2.2 [110/65] via 200.1.1.2, 00:50:53, Serial2/0
10.0.0.0/8 is variably subnetted, 3 subnets, 3 masks
C        10.1.1.0/24 is directly connected, Loopback1
L        10.1.1.1/32 is directly connected, Loopback1
O        10.2.1.0/24 [110/65] via 200.1.1.2, 00:03:54, Serial2/0
200.1.1.0/24 is variably subnetted, 2 subnets, 2 masks
C        200.1.1.0/24 is directly connected, Serial2/0
L        200.1.1.1/32 is directly connected, Serial2/0

the bgp network being advertised is a /16 whereas the best that the route table is doing is a /24… no component route from igp… NO SUBNET ROUTE…

here’s where we can use null0 to do the dirty…

R1(config)#ip route 10.1.0.0 255.255.0.0 null0
R1(config)#end
R1#
*Mar 13 14:04:48.943: %SYS-5-CONFIG_I: Configured from console by console
R1#sh ip bgp
Network          Next Hop            Metric LocPrf Weight Path
*>  10.1.0.0/16      0.0.0.0                  0         32768 i

problem solved… or make the interface and the network match…

R1(config-if)#ip add 10.1.1.1 255.255.0.0
R1(config-if)#end
R1#cl
*Mar 13 14:09:16.191: %SYS-5-CONFIG_I: Configured from console by console
R1#clear ip bgp *
R1#
*Mar 13 14:09:22.875: %BGP-5-ADJCHANGE: neighbor 2.2.2.2 Down User reset
*Mar 13 14:09:22.875: %BGP_SESSION-5-ADJCHANGE: neighbor 2.2.2.2 IPv4 Unicast topology base removed from session  User reset
*Mar 13 14:09:23.511: %BGP-5-ADJCHANGE: neighbor 2.2.2.2 Up
R1#sh ip bgp
R1#sh ip bgp
R1#sh ip bgp
R1#sh ip bgp
R1#sh ip bgp (and finally)
R1#sh ip bgp
BGP table version is 5, local router ID is 10.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i – IGP, e – EGP, ? – incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network          Next Hop            Metric LocPrf Weight Path
*>  10.1.0.0/16      0.0.0.0                  0         32768 i
*>  10.2.0.0/16      2.2.2.2                  0             0 65002 i

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

1.0.0.0/32 is subnetted, 1 subnets
C        1.1.1.1 is directly connected, Loopback0
2.0.0.0/32 is subnetted, 1 subnets
O        2.2.2.2 [110/65] via 200.1.1.2, 01:07:27, Serial2/0
10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
C        10.1.0.0/16 is directly connected, Loopback1
L        10.1.1.1/32 is directly connected, Loopback1
       10.2.0.0/16 [20/0] via 2.2.2.2, 00:02:54
200.1.1.0/24 is variably subnetted, 2 subnets, 2 masks
C        200.1.1.0/24 is directly connected, Serial2/0
L        200.1.1.1/32 is directly connected, Serial2/0