[afnog] BGP routing in multihomed environment

Tue Aug 28 14:24:10 UTC 2007

On Tuesday 28 August 2007 21:10, Bill Sangiwa wrote:

> ISP (AS36959) <-- RX ONLY-- Europe HUB (AS25228)--- NET
>
>                      ^
>                       ---TX/RX ----> Europe HUB(AS5377)
> ---- NET

Classic asymmetric routing with SCPC Tx on one end, DVB Rx on 
the other for AS25228 :-)... but on to the issue...

> from looking glass (router ID is 195.66.225.241), is see
> the routes via AS25228 are repeated
>
> <my network>  195.66.226.77    0   0 3356 25228 25228 25228
> 36959 i
>
> what could be wrong on the setup.

I think there is some information you haven't included or I 
don't understand what you mean by "routes via AS25228 are 
repeated".

Could you be referring to the multiple instances of AS25228's 
ASN in the AS_PATH?

If so...

> certainly that route is 
> not favoured and how to i make it more favoured?

I've looked at my border routers' BGP table as well as the 
ones on RIS (RIPE's Routing Information Service), and 
searching for all announcements from your ASN shows return 
traffic to some of your prefixes is preferred via AS25228. 

However, this only occurs when the AS_PATH is 
_8513_25228_36959$.

When the path is _3491_25228_25228_25228_25228_25228_36959$, 
traffic to some of your networks is preferred via your other 
upstream, AS5377 (because AS25228's AS_PATH is longer).

According to the ARIN WHOIS database, AS3491 belongs to PCCW 
Global while.

The RIPE WHOIS database says AS8513 belongs to SkyVision (who, 
incidentally, if memory serves, also run AS25228).

> will the 
> use of non-exist-map and the advertise-map keywords would
> help to overcome the problem?

Unlikely - this is a routing policy of AS25228. Suggest you 
log a ticket with their NOC and ask them why they prefer to 
prepend over their link to PCCW Global (economic reasons, 
e.g., expensive links, e.t.c. or technical reasons, e.g., 
less bandwidth on that link, e.t.c.) and whether they can 
announce your prefixes to PCCW Global unprepended.

Remember, networks can define their own routing policies. They 
may or may not be the best, but in many cases, we have to 
live with it :-).

Naturally, different networks have a different point of view 
of the Internet (routing) depending on how/where they are 
connected. For me, in south east Asia (Malaysia), I have a 
few more routes to your network via AS8513 than I see from 
RIS (Europe).

e.g., from one of my border router's, my best route to your 
prefix is via AS8513:

sh ip bgp 196.12.12.0
BGP routing table entry for 196.12.12.0/22, version 47243528
Paths: (4 available, best #2, table Default-IP-Routing-Table)

 2914 8513 25228 36959
    203.78.193.77 from 203.78.193.77 (203.78.192.1)
      Origin IGP, metric 0, localpref 100, valid, external, 
best
      Community: 2914:410 2914:2202 2914:3200

but from the LINX collector, it is:

BGP routing table entry for 196.12.12.0/22
Paths: (18 available, best #9, table Default-IP-Routing-Table)

8210 5377 36959
    195.66.226.107 from 195.66.226.107 (217.70.226.37)
      Origin IGP, localpref 100, valid, external, best
      Last update: Thu Aug  9 12:41:29 2007

So, YMMV.

But meanwhile, if you may be so kind as to indulge me...

>  bgp dampening

You might want to reconsider RFD (Route Flap Dampening). I 
think it might cause you more problems than it can solve.

>  neighbor 193.219.192.33 ebgp-multihop 255

Clearly you cannot avoid eBGP Multihop in your setup, but 
maybe you want to be a little stricter on the number of hops 
(I'm sure they are less than 255 :-) ).

>  neighbor 193.219.192.33 timers 60 1000

I'm trying to understand the reason you might explicitly set 
the BGP keepalive interval time (60 seconds is the default), 
but have a much higher hold time.

You have set a hold time of 16.7 minutes. What this means is 
that the router will not tear-down the BGP session to this 
neighbor for 16.7 minutes, even after it has not received any 
keepalive messages for the same amount of time. This could be 
dangerous, as it leads to keeping routes in the FIB that are 
less than useful, creating a blackhole for traffic.

If you are looking at fast BGP convergence, suggest you look 
at the BGP support for Next-Hop Address Tracking or BGP 
support for Fast Peering Session Deactivation features, 
available to certain platforms and Cisco IOS feature sets 
(not sure what platform you are running).

>  neighbor 193.219.192.33 soft-reconfiguration inbound

Unless you want to examine NLRI before policy is applied to 
it, would recommend you leave this feature turned off until 
you need it. Rather, use the Route Refresh capability, which 
is automatically enabled assuming IOS 12.0 and above.

Might save you some memory :-).

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
Url : http://afnog.org/pipermail/afnog/attachments/20070828/1331ccf6/attachment.bin 