[c-nsp] RES: conditional bgp default-originate

[Leonardo Gama Souza]

I haven't tested this, but you can configure two access-lists with both BGP session IP addresses of your upstream providers and match them in the route-map.
 
neighbor 10.1.0.2 default-originate route-map BGP-UP
 
route-map BGP-UP permit 10
 match ip address 101
 match ip address 102
route-map BGP-UP deny 20
 
access-list 101 permit ip host x.x.x.x
access-list 101 remark upstream provider 1 bgp session ip address
access-list 102 permit ip host y.y.y.y
access-list 102 remark upstream provider 2 bgp session ip address
 
Regards,
Leonardo Gama.
________________________________

De: cisco-nsp-bounces at puck.nether.net em nome de Jon Lewis
Enviada: qua 13/8/2008 12:50
Para: cisco-nsp at puck.nether.net
Assunto: [c-nsp] conditional bgp default-originate



I'd like to be able to conditionally advertise a default route to
customers taking just default routes only if my transit BGP sessions
appear to be functional.

I thought something like this might work:

  neighbor 10.1.0.2 default-originate route-map BGP-UP

route-map BGP-UP permit 10
  match as-path 100

ip as-path access-list 100 permit ^3356_
ip as-path access-list 100 permit ^4323_

But no such luck.  Checking the docs at

http://www.cisco.com/en/US/docs/ios/12_3/iproute/command/reference/ip2_n1g.html#wp1037042

it seems I have to exactly match against a route for the route-map to work
here.  That means actually picking a few "canary routes" I expect to get
from my upstreams and hoping they don't go anywhere or change mask.  I'm
not really happy with that.  Are there better ways to do this?

Also, while looking at the docs above and experimenting in the GNS3
simulator (emulated 2600s running c2600-i-mz.123-26.bin), I've found a few
oddities.

First, there's multiple errors in the docs mentioned above.  i.e. From the
URL above:

  In the following example, the last line of the configuration has been
  changed to show the use of an extended access list. The local router
  injects route 0.0.0.0 to the neighbor 172.16.2.3 only if there is a route
  to 192.168.0.0 with a mask of 255.255.0.0:

  router bgp 50000
   network 172.16.0.0
   neighbor 172.16.2.3 remote-as 60000
   neighbor 172.16.2.3 default-originate route-map default-map
  !
  route-map default-map 10 permit
   match ip address 1
  !
  access-list 100 permit ip host 192.168.0.0 host 255.255.255.0

In the above example, they did change the ACL to an extended access-list,
but the route-map wasn't updated to use it (still using 1) and they say
they're looking for 192.168.0.0 with a mask of 255.255.0.0, but the
access-list 100 uses a /24 mask.

Just above this example, the docs say that
  access-list 1 permit 192.168.0.0
will match a route for 192.168.0.0 with any mask.  In my simulator, I have
R1--R2--R3
R1 advertises 8.0.0.0/16 to R2.  R2 is advertising a conditional default
to R3 using the route-map

route-map BGP-UP permit 10
  match ip address 50

access-list 50 permit 8.0.0.0

When R2 receives 8.0.0.0/16 from R1, there are no hits on the ACL and
default is not sent ot R3.  If I add to access-list 50
access-list 50 permit 8.0.0.0 0.0.255.255

Standard IP access list 50
     10 permit 8.0.0.0 (973 matches)
     20 permit 8.0.0.0, wildcard bits 0.0.255.255

I get hits on the permit 8.0.0.0 line now, and default is sent to R3.
This seems kind of broken.  I haven't duplicated the setup with real
hardware to see if it's a simulator screwup...but since the simulator is
running actual IOS, it seems unlikely the simulator is to blame.

----------------------------------------------------------------------
  Jon Lewis                   |  I route
  Senior Network Engineer     |  therefore you are
  Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
_______________________________________________
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/