[j-nsp] BGP troubleshooting

[David Ball]

  In your illustration of the border2 problem, is your border1's BGP
session up at the time as well?  It looks as though the hop after your
ISPs router 1.1.1.1.75 (invalid IP!  Danger Will Robinson!) doesn't
have a route to get back to your border2, or perhaps the route it
knows takes another path (perhaps through your border1?).  Assuming
you're doing iBGP between your border routers, and your ISP has an
iBGP mesh as well, this shouldn't be a problem, unless there are some
policies/filters somewhere doing something naughty.

1.  Check to see if you're sending all of your routes out both of your
BGP sessions (sh route advertise-protocol bgp peer.ip.address)
2.  Ask your ISP if they're receiving all of the routes you're sending
on both of their routers
3.  Both you and your ISP should check log files for other stuff,
although the fact the session comes up but you're receiving no routes
via border2 sounds more like a policy thing, either on your side
(import policy) or theirs (export policy).

David


2008/11/1 Campbell, Alex <Alex.Campbell at ogilvy.com.au>:
> Hi all,
>
>
>
> We have run into a BGP issue bringing up a new ISP on our J4350s and I
> have been struggling to figure out what's going on.  If anyone has any
> troubleshooting suggestions or ideas as to what might be doing wrong, I
> would be most grateful.
>
>
>
> We have two border routers, each connected to a separate port with the
> same ISPs.  The interface IPs on those ports are
>
> border1: 1.1.1.1.76/29
>
> border2: 1.1.1.1.77/29
>
>
>
> border1 is configured to bring up a multihop BGP session with ISP's
> router at 2.2.2.2.  We have added a static route on border1 to
> 2.2.2.2/32 with a next-hop of 1.1.1.1.73.  This works correctly and
> border1 receives a full table of around 251,000 routes.
>
>
>
> border2 is configured to bring up a multihop BGP session with ISP's
> router at 3.3.3.3.  We have added a static route on border2 to
> 3.3.3.3/32 with a next-hop of 1.1.1.1.73.
>
>
>
> The problem is that when we allow border2 to bring up its BGP session
> with the ISP router, the session comes up successfully but the device
> receives 0 routes from the ISP router, and we lose complete internet
> connectivity.
>
>
>
> This is what we see on border2 after bringing up the session:
>
>
>
> =============================================================
>
>
>
> alex at border2# run show bgp summary
>
> Groups: 2 Peers: 2 Down peers: 0
>
> Table          Tot Paths  Act Paths Suppressed    History Damp State
> Pending
>
> inet.0            250985     250972          0          0          0
> 0
>
> Peer               AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn
> State|#Active/Received/Damped...
>
> 5.5.5.1    24438      67593        103       0       0       43:56
> 250972/250985/0      0/0/0
>
> 3.3.3.3   9443          1          4       0       0          20 0/0/0
> 0/0/0
>
> =============================================================
>
>
>
> Here's an example traceroute of what happens from a machine on our
> network after we bring up border2's BGP session to ISP:
>
>
>
> =============================================================
>
>
>
> C:\Users\a>tracert www.google.com.au
>
>
>
> Tracing route to www.l.google.com [209.85.171.147]
>
> over a maximum of 30 hops:
>
>
>
>  1    <1 ms    <1 ms    <1 ms  red2.fw1.mel1.x.com.au [6.6.6.1]
>
>  2    23 ms    28 ms    29 ms  border2 [5.5.5.35]
>
>  3    23 ms    29 ms    29 ms  ge-0-0-2.border1.mel1.x.com.au
> [5.5.5.17]
>
>  4     1 ms     1 ms     1 ms  075.196.idc.ourisp.net.au [1.1.1.1.75]
>
>  5     *        *        *     Request timed out.
>
>  6     *        *        *     Request timed out.
>
>  7     *        *        *     Request timed out.
>
>  8     *        *        *     Request timed out.
>
>
>
> =============================================================
>
>
>
> Here's an example of what happens from a machine on our network after we
> shutdown border2's BGP session to ISP:
>
>
>
> C:\Users\a>tracert www.google.com.au
>
>
>
>
> Tracing route to www.l.google.com [209.85.171.103]
>
> over a maximum of 30 hops:
>
>
>
>  1    <1 ms    <1 ms    <1 ms  red2.fw1.mel1.x.com.au [6.6.6.1]
>
>
>
>  2    27 ms    29 ms    29 ms  border2 [5.5.5.35]
>
>  3    25 ms    29 ms    18 ms  ge-0-0-2.border1.mel1.x.com.au
> [5.5.5.17]
>
>  4     1 ms     1 ms     1 ms  075.196.idc.ourisp.net.au [1.1.1.1.75]
>
>  5     1 ms     1 ms     1 ms  ge4-15.sw02.mel.ourisp.net.au
> [210.50.0.9]
>
>  6   132 ms     2 ms     2 ms  210.50.233.202
>
>  7   170 ms   170 ms   170 ms  p3-0.pr1-lax.primustel.com
> [209.227.149.241]
>
>  8   170 ms   173 ms   171 ms  g9-0.pr1-lax.primustel.com
> [209.227.129.141]
>
>  9   172 ms   172 ms   172 ms  209.227.129.62
>
>  10   172 ms   174 ms   173 ms  core2-1-1-0.pao.net.google.com
> [198.32.176.31]
>
>  11   175 ms   175 ms   174 ms  216.239.49.250
>
>  12   210 ms   198 ms   197 ms  216.239.47.186
>
>  13   205 ms   189 ms   195 ms  216.239.46.211
>
>  14   190 ms   192 ms   194 ms  64.233.174.97
>
>  15   191 ms   200 ms   190 ms  209.85.251.141
>
>  16   189 ms   190 ms   203 ms  74.125.31.134
>
>  17   189 ms   191 ms   190 ms  cg-in-f103.google.com [209.85.171.103]
>
>
>
> Trace complete.
>
>
>
> =============================================================
>
>
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>