RE: BGP Reachability Qns

From: Huan Pham (Huan.Pham@peopletelecom.com.au)
Date: Thu Dec 11 2008 - 04:43:51 ARST


Hi Nitro,

Your mail is a long one, so I have only scanned for your general
questions, and can just give you generatl answer.

Qns 1.) How come R5 is able to ping to the BGP prefixs (112.0.0.1)
learned from BB1 even though BB1 does not have any any BGP
aggregates/prefixes back to the internal network or back to R5?

BB1 has to have a route back to R5, in order to for the pings to be
successful. For studying purpose, log on to BB1, and show ip route back
to R5, and see how that route is leant.

BB1 does not need to use BGP route to reach R5. It can use ANY route,
e.g. IGP, or static, default route to get back to R5.

Qns 2.) How come R5 is NOT able to ping to the BGP prefixs (112.0.0.1)
learned from BB3? Whereas it is able to from BB1?

Same methodology as in Q1, you need to look in more details routing
table learnt by BB1, and do trace (from both R5 and BB1) and see where
the ping get stuck. Pinging alone will not help indentifying the routing
problem!

Qns3.) So in the lab exam, does full reachability includes reachabillity
to BGP prefixes learnt from BB routers?

Not always required! Read the reaquirement at the beginning of the lab
workbook, and the routing session tasks. Should best ask proctor for
clarification.

Even if it is required full reachibility, failed pings does not mean
that you do not have reachibility. For reachibility within routers that
you can control, I definitely assume that I have to be able to ping one
router to other. If I do not have that, trouble-shoot and see why not!
For external routes advertized from BB, do not emphasis too much on
successful pings. The BB may intentially have ACL to block pings, but
allow all normal traffic. Also, the interface IP of those route may be
ended with anything between .1 and .254, which one you assume? Will you
ping all 254 addresses?

When full reachibility is required, make sure that you advertize your
networks out to BB (normally summary is enough), and you receive
required routes from BB. Tracing from your internal routers to BB
routes, if it stop at the BB routers, then it is mostlikely OK, and you
can move on.

Cheers,

Huan

-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Nitro Drops
Sent: Wednesday, 10 December 2008 9:44 PM
To: ccielab@groupstudy.com
Subject: BGP Reachability Qns

Hi All,

Need some technical expertise to clear some doubts and concepts. Have
been reading tonnes of notes, maybe i am slow 8(

Pardon me for this long scenario, and thank you for your patience.

R5 > R4 > R6 > BB1 (AS54)
R5 > R3 > BB3 (AS54)

R3, R4, R5, R6 all in AS100.

R5 has IGP reachability to BB1 (54.1.1.254) and BB3 (204.12.1.254)

Rack1R5#sh ip route 204.12.1.254
Routing entry for 204.12.1.0/24
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward
metric
64
  Redistributing via eigrp 100
  Advertised by eigrp 100 metric 1 1 1 1 1
  Last update from 183.1.0.3 on Serial1/0, 00:09:02 ago
  Routing Descriptor Blocks:
  * 183.1.0.3, from 150.1.3.3, 00:09:02 ago, via Serial1/0
      Route metric is 20, traffic share count is 1

Rack1R5#ping 204.12.1.254
!!!!!

Rack1R5#sh ip route 54.1.1.254
Routing entry for 54.1.1.0/24
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward
metric 110
  Redistributing via eigrp 100
  Advertised by eigrp 100 metric 1 1 1 1 1
  Last update from 183.1.45.4 on Ethernet0/1, 00:15:33 ago
  Routing Descriptor Blocks:
  * 183.1.45.4, from 150.1.6.6, 00:15:33 ago, via Ethernet0/1
      Route metric is 20, traffic share count is 1

Rack1R5#ping 54.1.1.254
!!!!!

Rack1R5#sh ip bgp
BGP table version is 346, local router ID is 150.1.5.5 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
*>i28.119.16.0/24 204.12.1.254 0 100 0 54 i
* i 54.1.1.254 0 100 0 54 i
*>i28.119.17.0/24 204.12.1.254 0 100 0 54 i
* i 54.1.1.254 0 100 0 54 i
*>i112.0.0.0 204.12.1.254 0 100 0 54 50 60 i
* i 54.1.1.254 0 100 0 54 50 60 i
*>i113.0.0.0 204.12.1.254 0 100 0 54 50 60 i
* i 54.1.1.254 0 100 0 54 50 60 i
*>i114.0.0.0 204.12.1.254 0 100 0 54 i
* i 54.1.1.254 0 100 0 54 i
*>i115.0.0.0 204.12.1.254 0 100 0 54 i
* i 54.1.1.254 0 100 0 54 i
*>i116.0.0.0 204.12.1.254 0 100 0 54 i
* i 54.1.1.254 0 100 0 54 i
*>i117.0.0.0 204.12.1.254 0 100 0 54 i
* i 54.1.1.254 0 100 0 54 i
*>i118.0.0.0 204.12.1.254 0 100 0 54 i
   Network Next Hop Metric LocPrf Weight Path
* i 54.1.1.254 0 100 0 54 i
*>i119.0.0.0 204.12.1.254 0 100 0 54 i
* i 54.1.1.254 0 100 0 54 i
* i150.1.11.0/24 183.1.123.1 0 100 0 200 i
*> 183.1.105.10 0 200 i
* i205.90.31.0 183.1.123.1 0 100 0 200 254 ?
*> 183.1.105.10 0 200 254 ?
* i220.20.3.0 183.1.123.1 0 100 0 200 254 ?
*> 183.1.105.10 0 200 254 ?
* i222.22.2.0 183.1.123.1 0 100 0 200 254 ?
*> 183.1.105.10 0 200 254 ?
Rack1R5#

When connection between R3 & BB3 is down. BGP routes from Backbone are
learnt from BB1

Rack1R5#sh ip bgp
BGP table version is 356, local router ID is 150.1.5.5 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
*>i28.119.16.0/24 54.1.1.254 0 100 0 54 i
*>i28.119.17.0/24 54.1.1.254 0 100 0 54 i
*>i112.0.0.0 54.1.1.254 0 100 0 54 50 60 i
*>i113.0.0.0 54.1.1.254 0 100 0 54 50 60 i
*>i114.0.0.0 54.1.1.254 0 100 0 54 i
*>i115.0.0.0 54.1.1.254 0 100 0 54 i
*>i116.0.0.0 54.1.1.254 0 100 0 54 i
*>i117.0.0.0 54.1.1.254 0 100 0 54 i
*>i118.0.0.0 54.1.1.254 0 100 0 54 i
*>i119.0.0.0 54.1.1.254 0 100 0 54 i

When connection between R6 & BB1 is down. BGP routes from Backbone are
learnt from BB3

Rack1R5#sh ip bgp
BGP table version is 406, local router ID is 150.1.5.5 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
*>i28.119.16.0/24 204.12.1.254 0 100 0 54 i
*>i28.119.17.0/24 204.12.1.254 0 100 0 54 i
*>i112.0.0.0 204.12.1.254 0 100 0 54 50 60 i
*>i113.0.0.0 204.12.1.254 0 100 0 54 50 60 i
*>i114.0.0.0 204.12.1.254 0 100 0 54 i
*>i115.0.0.0 204.12.1.254 0 100 0 54 i
*>i116.0.0.0 204.12.1.254 0 100 0 54 i
*>i117.0.0.0 204.12.1.254 0 100 0 54 i
*>i118.0.0.0 204.12.1.254 0 100 0 54 i
*>i119.0.0.0 204.12.1.254 0 100 0 54 i

In both BB1 and BB3, there are no aggregate routes back to the internal
network

BB3(config-router)#do sh ip bgp
BGP table version is 135, local router ID is 31.3.0.1 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
*> 28.119.16.0/24 0.0.0.0 0 32768 i
*> 28.119.17.0/24 0.0.0.0 0 32768 i
*>i112.0.0.0 172.16.4.1 0 100 0 i
*>i113.0.0.0 172.16.4.1 0 100 0 i
*>i114.0.0.0 172.16.4.1 0 100 0 i
*>i115.0.0.0 172.16.4.1 0 100 0 i
*>i116.0.0.0 172.16.4.1 0 100 0 i
*>i117.0.0.0 172.16.4.1 0 100 0 i
*>i118.0.0.0 172.16.4.1 0 100 0 i
*>i119.0.0.0 172.16.4.1 0 100 0 i
*> 150.1.11.0/24 204.12.1.3 0 100 200 i
* i 172.16.4.1 0 100 0 100 200 i
*> 205.90.31.0 204.12.1.3 0 100 200 254
?
* i 172.16.4.1 0 100 0 100 200 254
?
*> 220.20.3.0 204.12.1.3 0 100 200 254
?
* i 172.16.4.1 0 100 0 100 200 254
?
*> 222.22.2.0 204.12.1.3 0 100 200 254
?
   Network Next Hop Metric LocPrf Weight Path
* i 172.16.4.1 0 100 0 100 200 254
?
BB3(config-router)#

BB1#sh ip bgp
BGP table version is 111, local router ID is 212.18.3.1 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
*>i28.119.16.0/24 172.16.4.3 0 100 0 i
*>i28.119.17.0/24 172.16.4.3 0 100 0 i
*> 112.0.0.0 0.0.0.0 0 32768 i
*> 113.0.0.0 0.0.0.0 0 32768 i
*> 114.0.0.0 0.0.0.0 0 32768 i
*> 115.0.0.0 0.0.0.0 0 32768 i
*> 116.0.0.0 0.0.0.0 0 32768 i
*> 117.0.0.0 0.0.0.0 0 32768 i
*> 118.0.0.0 0.0.0.0 0 32768 i
*> 119.0.0.0 0.0.0.0 0 32768 i
*> 150.1.11.0/24 54.1.1.6 0 100 200 i
* i 172.16.4.3 0 100 0 100 200 i
*> 205.90.31.0 54.1.1.6 0 100 200 254
?
* i 172.16.4.3 0 100 0 100 200 254
?
*> 220.20.3.0 54.1.1.6 0 100 200 254
?
* i 172.16.4.3 0 100 0 100 200 254
?
*> 222.22.2.0 54.1.1.6 0 100 200 254
?
   Network Next Hop Metric LocPrf Weight Path
* i 172.16.4.3 0 100 0 100 200 254
?
BB1#

Qns 1.) How come R5 is able to ping to the BGP prefixs (112.0.0.1)
learned from BB1 even though BB1 does not have any any BGP
aggregates/prefixes back to the internal network or back to R5?

<Connection between R3 & BB3 is down>

Rack1R5#ping 112.0.0.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 112.0.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/133/292
ms

Rack1R5#sh ip route 112.0.0.1
Routing entry for 112.0.0.0/8
  Known via "bgp 100", distance 200, metric 0
  Tag 54, type internal
  Last update from 54.1.1.254 00:02:38 ago
  Routing Descriptor Blocks:
  * 54.1.1.254, from 150.1.6.6, 00:02:38 ago
      Route metric is 0, traffic share count is 1
      AS Hops 3
      Route tag 54

Rack1R5#sh ip bgp 112.0.0.1
BGP routing table entry for 112.0.0.0/8, version 423
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
  Advertised to update-groups:
     1 2
  54 50 60, (Received from a RR-client)
    54.1.1.254 (metric 20) from 150.1.6.6 (150.1.6.6)
      Origin IGP, metric 0, localpref 100, valid, internal, best
Rack1R5#

Qns 2.) How come R5 is NOT able to ping to the BGP prefixs (112.0.0.1)
learned from BB3? Whereas it is able to from BB1?

Rack1R5#ping 112.0.0.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 112.0.0.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

Rack1R5#sh ip bgp 112.0.0.1
BGP routing table entry for 112.0.0.0/8, version 438
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
  Advertised to update-groups:
     1 2
  54 50 60, (Received from a RR-client)
    204.12.1.254 (metric 20) from 183.1.0.3 (150.1.3.3)
      Origin IGP, metric 0, localpref 100, valid, internal, best
Rack1R5#sh ip bgp 112.0.0.1 BGP routing table entry for 112.0.0.0/8,
version 438
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
  Advertised to update-groups:
     1 2
  54 50 60, (Received from a RR-client)
    204.12.1.254 (metric 20) from 183.1.0.3 (150.1.3.3)
      Origin IGP, metric 0, localpref 100, valid, internal, best
Rack1R5#

I am not able to figure out the results of Qns1. My understanding is for
BGP

i.) there must be an underlying L2 IGP protocol for BGP to learn best
routes
ii.) Routing is a bi-directional process, for R5 to ping to Backbone
route 112.0.0.1, R5 must have a BGP route to it and vice versa meaning
the BB1 and
BB3 must have a BGP route back to R5.

In the above scenario, both BB1 and BB3 (i) dont have an BGP aggregate
routes back to the internal network nor (ii) have a BGP route to R5. But
how come R5 is able to ping Backbone route 112.0.0.1 via through BB1 and
not BB3.

To make R5 able to ping 112.0.0.1 via through BB3, i advertise an
internal subnet onto R5 via BGP, and R5 is able to ping to 112.0.0.1
from the source which is advertised into BGP.

Qns3.) So in the lab exam, does full reachability includes reachabillity
to BGP prefixes learnt from BB routers?

Quoted from Brian McGahan

It is always an implicit
requirement that you have to have an IGP route to the next-hop of a BGP
learned prefix. This means that either you need an IGP route to the link
between the EBGP neighbors or you need to modify the next-hop value with
the next-hop-self command or manually with a route-map and the "set ip
next-hop" command.

Does it mean we just need to emphasize on IGP reachability to the
next-hop ONLY of a BGP learned prefix?

Pretty weak in BGP, just want to get all my concepts right. Have been
trying this for the last 4 hours.

Thank you for any kind replies.

Cheers
Nit



This archive was generated by hypermail 2.1.4 : Thu Jan 01 2009 - 12:53:08 ARST