[c-nsp] Showing alternate BGP paths

[Kanagaraj Krishna]

Hi guys,
            Sorry for the late reply as I was away. Thanks for your feedback. As mentioned, we do use RR for our iBGP on 2 internal core switch (Layer 3) to save processing power on the other peer routers. They are the centralized processing core (hub & spoke) with all the border and internal routers. My questions are:

- If i change the setup to a fully meshed iBGP network (minus RR), is there a way to see alternative paths with lower   
  local preference as well with "sh ip bgp xxx.xxx.xxx.xxx"?
- As we know eBGP routes are more prefered to iBGP routes, which explains why the internal one is also not shown  
  as an alternative path unless the eBGP routes are down. Anyway to view iBGP routes as well other than through its  
  directly connected node?

Thanks again.

Kana
  ----- Original Message ----- 
  From: Oliver Boehmer (oboehmer) 
  To: Karol Mares 
  Cc: Kanagaraj Krishna ; cisco-nsp at puck.nether.net 
  Sent: Thursday, September 14, 2006 5:46 PM
  Subject: RE: [c-nsp] Showing alternate BGP paths


  Karol,

  your output shows a lab router receiving two paths from two different
  neighbors. This router can do multipath (and if it does multipath, it
  can perform unequal-cost multipath using dmzlink-bw), but it will still
  select *one* best path and will only send this one best-path to its
  neighbors.
  You usually run into this limitation when you have route reflectors,
  i.e. the following BGP topology:

  eBGP GW1  --\
               ---- RR --- router1
  eBGP GW2  --/

  Assuming the RR is not in the forwarding path: Even if router1 could use
  multipath with both gateways to reach a certain prefix, the RR only
  sends one of the two to router1, so in effect one of two paths is not
  used.  

  oli

  Karol Mares <mailto:KMares at soitron.com> wrote on Thursday, September 14,
  2006 10:43 AM:

  > Hi Oli,
  > 
  > I thought , that the new feature bgp dmzlink-bw, is used for this
  > purpose. As i can see, both load-balanced routes are propagate
  > through the IBGP/EBGP path. 
  > 
  > 
  > lab# show ip bgp 10.1.1.0
  > BGP routing table entry for 10.1.1.0/24, version 48
  > Paths: (2 available, best #2)
  > Multipath: eBGP
  >   Advertised to update-groups:
  >      1          2
  >   200
  >     172.16.1.1 from 172.16.1.2 (10.1.1.1)
  >       Origin incomplete, metric 0, localpref 110, valid, external,
  >       multipath, best Extended Community: 0x0:0:0
  >       DMZ-Link Bw 512 kbytes
  >   200
  >     172.16.2.2 from 172.16.2.2 (10.1.1.1)
  >       Origin incomplete, metric 0, localpref 110, valid, external,
  >       multipath, best Extended Community: 0x0:0:0
  >       DMZ-Link Bw 625 kbytes
  > 
  > The output shows that a route for each exit link on lab router  to
  > autonomous system 200 has been installed as a best path i
  > n the BGP routing table.
  > 
  >                    iso
  > 
  > On Thu, 2006-09-14 at 09:36 +0200, Oliver Boehmer (oboehmer) wrote:
  >> cisco-nsp-bounces at puck.nether.net <> wrote on :
  >> 
  >>> Hi,
  >>>     We have a setup with 3 routers running BGP connecting to our
  >>> upstream provider and iBGP with the other routers on our local
  >>> network. Usually, when the "sh ip bgp xxx.xxx.xxx", is used we can
  >>> see: 
  >>> 
  >>> - the best path
  >>> - other alternative paths with the same local preference
  >>> 
  >>> Is it possible to also view paths with less local preference
  >>> and inactive routes? At the moment we have to run the command on
  >>> the router that is directly connected to a certain upstream (eBGP)
  >>> to view available paths from them which we can't see from our
  > iBGP routers.
  >> Thanks.
  >> 
  >> No, BGP only sends the best path to its peers, so if you receive
  >> multiple paths from eBGP peers, the knowledge of the non-best-path
  >> is limited to these nodes. 
  >> 
  >> There are some efforts to change the BGP protocol to send multiple
  >> paths (essentially to allow load-balancing), but this has not been
  >> finalized and implemented anywhere yet (as far as I know)..
  >> 
  >> oli
  >> 
  >> _______________________________________________
  >> cisco-nsp mailing list  cisco-nsp at puck.nether.net
  >> https://puck.nether.net/mailman/listinfo/cisco-nsp
  >> archive at http://puck.nether.net/pipermail/cisco-nsp/