[j-nsp] Route Advertisement using Communities.

[Kevin Epperson]

You could do this by reordering the statements.  Something like:

    policy-statement peer-0 {
       term 5 {
            from {
                community customers;
                community no-att-global;
                }
            then reject;
        }
       term 10  {
             from community customers;
             then accept;
        }
        then reject;
    }

You could also split these into multiple policies if you wanted to keep
some standard filtering you use on all peers in the first policy and the
specific bits for that peer in the second policy.

    policy-statement peer-sanity-filtering {
       term 5-XX
          martian/etc filtering
       term YY {
            from {
                community customers;
                }
            then next-policy;
          }
        then reject;
     }

      policy-statement peer-X {
       term 5 {
            from {
                community no-att-global;
                }
            then reject;
            }
          then accept;
        }

In this case the import policy would be something like:
  [ peer-sanity-filtering peer-X ]

There might be some more graceful ways to do some of this...but that is
what came to mind.  I didn't check any of that for syntax...but I think it
is roughly along the right track.

	-Kevin

On Fri, 4 Mar 2005, Dan Benson wrote:

> I am currently using communities to advertise customers routes to my
> upstream providers globally, but as my network grows I want to be able
> to have my customers choose what carriers their routes are set to and
> where.  In my lab, I am making policy statements that will take my
> customer routes, Tagged as say 65000:1001, and advertise them.  The
> customer routes are tagged on the edge router that the customer peers
> with to allow us to redistribute this to our peers and upstream
> networks.  This is all working perfectly, now what I am trying to do is
> allow for the customer to tag the routes they send to us as well, and
> depending on the tag they send, have my network handle the route
> differently.
>
> Example:  I have a route from a customer BGP session, say AS65555, route
> 192.168.0.0/24. My network's edge router tags the route with a community
> 65000:1001  .I want the customer to be able to tag the routes with
> additional communities to allow the customers routes to be advertised in
> certain places or not.  In this case, the customer tags their route with
> a community of 65000:2003.  On my edge routers that connect to my peers
> and my upstreams, I will see the route as 192.168.0.0/24 with the
> communities of 65000:1001 and 65000:2003.  When I try and tell my
> routers to advertise the route based on the first tag, 65000:1001, they
> do just fine.  The Second I try and drop a route because of another tag,
> it continues to advertise the route.  I am assuming this is because I
> accept on the first tag and then try and drop on the second.  I would
> have assumed that the hierarchy of my terms would follow suit, but this
> does not seem to be the case.  Example of my policy statement:
>
>
>     policy-statement peer-0 {
>         term 5 {
>             from community customers;
>             then accept;
>        }
>        term 10  {
>              from community no-att-global;
>              the reject;
>        }
>         then reject;
>
>
> community no-att-global members 65000:2003
> community customers members  65000:1001
>
> Thanks in advance for the assistance..   //db
>
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> http://puck.nether.net/mailman/listinfo/juniper-nsp
>