[OCCAID] Quagga communities and route preferencing

[James]

On Sun, Jan 09, 2005 at 04:47:39AM -0800, Tyler Delane wrote:
> Hi there.
> 
> To date, I've been operating on a pretty bare bones BGP setup.  Pretty much 
> all I'm doing is applying inbound and outbound prefix filters, with no 
> futher route-map'ing or preferencing.
> 
> So, does anyone have any suggestions on somewhere to start?
> 
> Looking at the OCCAID BGP community listing, I can use that as a template, 
> but does anyone have any advice and/or configuration examples for setting 
> localprefs and other attributes by applying communities via route-maps?
> 
> I look forward to seeing some clueful response, and having a break from all 
> this reverse DNS nonsense ;)
> 
> - Tyler

Let's assume the following setup:

              Identifying Community                Local Preference
Customers     64512:3000                           350
Peers         64512:2000                           110
Transits      64512:1000                           100
Internal      64512:9000                           400

Now, let's see how we do this on the route-map's. We set an inbound route-map
on every customer BGP sessions (use peer-group to simplify configuration and
processing overhead) to mark the customer-sent routes to local preference of
350 and tag it with community of 64512:3000.

!
route-map customer-in permit 5
 set local-pref 350
 set community 64512:3000 additive
!

On peers' sessions you would have:

!
route-map peers-in permit 5
 set local-pref 110
 set community 64512:2000 additive
!

On transits, same thing except LP (local pref) is 100, community is 64512:1000.


Now, here is where communities and routing policy become useful. Let us assume
that you have established peering with AS111. Peering by definition means you
and your peer will only advertise your own and your downstream customer routes.
In other words, both parties give connectivity to either networks and
downstreams, but not to the whole internet.

So you need to configure a setup that will only send your routes and your
customer routes to AS111. While using prefix-list/filter-list manually is fine,
when the network becomes large enough (i.e. OCCAID 30071 network) you will run
into scalability problems that will get out of control, if not using comm's.

So to set up a route-map OUTBOUND to your AS111 peering session, that will only
advertise your own and your downstream customer routes would be:

!
ip community-list standard PEERING permit 64512:9000
ip community-list standard PEERING permit 64512:3000
!
route-map PEERING-OUT permit 5
 match community PEERING
!
route-map PEERING-OUT deny 10

Notice the 'deny' statement after the first one. It will deny sending all routes
to your peer other than those matching 64512:9000 (internal) and 64512:3000
(customer).


For more complex setup, you can view the old 2003 configuration of OCCAID DFW
router that was posted in the past.

http://mailman.twdx.net/pipermail/occaid/2004-January/000519.html

It's quite old now and some things are changed since then, but most of it is
same in the framework of the configuration, and you should be able to see most
of advanced stuff we are doing with it.

Feel free to ask additional Q's.

-J
-- 
James Jun                                            TowardEX Technologies, Inc.
Technical Lead                      Boston IPv4/IPv6 Web Hosting, Colocation and
james at towardex.com            Network design/consulting & configuration services
cell: 1(978)-394-2867           web: http://www.towardex.com , noc: www.twdx.net