[c-nsp] Dumb question

[Ziv Leyes]

The RTR1-IN route-map is for filtering the incoming routes

So you're saying that the statement 
match community 100:1 which is the community itself won't work?
Do I need here as well to match the community on a list and then use the community list on the route-map in too?
Then why when you configure it lets you do it?
Nevermind, I've adjusted the settings to work with a community list and then match the list on the route-map on both directions, incoming route-map from RTR1 and outgoing route-map to ISP1 and guess what?
I can see them now going out!

RTR2# sh ip bgp neighbor z.z.z.z advertised
   Network          Next Hop            Metric LocPrf Weight Path
*>i1.1.1.0/24   y.y.y.y           0    100      0 i
*>i2.2.2..0/24   y.y.y.y           0    100      0 i

Yeehaw!

So the problem was basically with the route-map in from RTR1 which didn't actually match a community list, I tried matching the community itself (duh)

Thanks Gert for all the inline clarifications on every step
And thanks you all the rest for all your help!
Ziv



-----Original Message-----
From: Gert Doering [mailto:gert at greenie.muc.de] 
Sent: Wednesday, August 03, 2011 7:02 PM
To: Ziv Leyes
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Dumb question

Hi,

On Wed, Aug 03, 2011 at 06:44:07PM +0300, Ziv Leyes wrote:
>  neighbor RTR1 route-map RTR1-IN in

What's that for?

>  neighbor ISP1 remote-as 11111
>  neighbor z.z.z.z peer-group ISP1
>  neighbor ISP1 send-community
>  neighbor ISP1 route-map ISP1-OUT out
> (similar settings for ISP2, with opposite prepending settings)
>   
> ip bgp-community new-format
> ip community-list standard COMMUNITY-1 permit 100:1 ip community-list 
> standard COMMUNITY-2 permit 100:2 !
> route-map RTR1-IN permit 10
>  match community 100:1
> !
> route-map RTR1-IN permit 20
>  match community 100:2

Whatever it is, it won't work, as you're trying to match on a community list named "100:1", not "the community 100:1".

It might actually do interesting things, as the prefixes will never be matched, and fall off the end of the route-map - if there's an implicit "deny" there [of which I'm never sure with route-maps] RTR2 will just reject prefixes from RTR1, and that might be why you don't see the
*outgoing* announcements towards ISP1 and ISP2.

> !
> route-map ISP1-OUT permit 10
>  match community COMMUNITY-1
> !
> route-map ISP1-OUT permit 20
>  match community COMMUNITY-2
>  set as-path prepend 100 100 100 100
> !

Now this looks very reasonable.

> Now, checking what I see, I get the following:
> 
> RTR1# sh ip bgp neighbor x.x.x.x advertised
>    Network          Next Hop            Metric LocPrf Weight Path
> *> 1.1.1.0/24   0.0.0.0                  0         32768 i
> *> 2.2.2.0/24   0.0.0.0                  0         32768 i
> 
> RTR2# sh ip bgp neighbor y.y.y.y received-routes
>    Network          Next Hop            Metric LocPrf Weight Path
> * i1.1.1.0/24   207.226.45.254           0    100      0 i
> * i2.2.2.0/24   207.226.45.254           0    100      0 i

Looking in "received-routes" won't tell you whether it actually accepted the route...

> RTR2# sh ip bgp 1.1.1.0
> BGP routing table entry for 1.1.1.0/24, version 7234660
> Paths: (1 available, no best path)
>   Not advertised to any peer
>   Local, (Received from a RR-client), (received-only)
>     y.y.y.y (metric 100) from y.y.y.y (y.y.y.x)
>       Origin IGP, metric 0, localpref 100, valid, internal
>       Community: 100:1

... which it didn't!  It's "received-only", not "active in RTR2's BGP table".

> BUMMER!!!!
> 
> What I do find very strange is the following:
> route-map RTR1-IN, permit, sequence 10
>   Match clauses:
>     community (community-list filter): 100:1 
>   Set clauses:
>   Policy routing matches: 0 packets, 0 bytes route-map RTR1-IN, 
> permit, sequence 20
>   Match clauses:
>     community (community-list filter): 100:2 
>   Set clauses:
>   Policy routing matches: 0 packets, 0 bytes
> 
> See? all the counters are zero!

Sure.  You have no community-list "100:1" and "100:2".

gert
--
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de

 
 
************************************************************************************
This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************




The information contained in this e-mail message and its attachments is confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender, and then delete the message from your computer.  Thank you!

******** This mail was sent via Mail-SeCure System.********



 
 
************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************