Adding and deleting communities...
Hi all, I need your help to understand what I'm missing... One of the rs clients sends a route with no-export community, so I have to strip it on ingress and re-attach it on egress. I thought I have two alternatives: using "interpret community no" in the bgp table of the peer, or playing with bgp_community.add and delete. I would expect to receive a "duplicate" network on my peering router, one learned via the direct peering and one learned via the route server. So far I only see the network from the direct peering. Relevant part of the config file: protocol pipe P_MYPEER { table master; mode transparent; peer table T_MYPEER; export where bgp_out(<mypeer>) = true; import where bgp_mypeer_in(<mypeer>) = true; } in the bgp_mypeer_in function, after checking that it is a legitimate network for that peer, I added: bgp_community.delete ((65535, 65281)); just before the final "return true". in the bgp_out function, after checking if a filtering community is set, I added: if (bgp_path.first = <mypeer>) then bgp_community.add ((65535, 65281)); just before the final "return true". I also set "interpret community no" in protocol bgp MYPEER. If I issue a "show route where bgp_path.first=<my-peer> all" I see that the no-export community is actually being stripped, but I still see one network on my peering router (sh ip bgp regexp ^<mypeer>, via the direct peering). TIA for any help, Simone. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Hi Simone, On 20.05.2010 16:41 Simone Morandini wrote
I need your help to understand what I'm missing... One of the rs clients sends a route with no-export community, so I have to strip it on ingress and re-attach it on egress.
actually I wouldn't do resp. interprete ist that way. If customer sets no-export, then simply do not export that prefix. If customer really wants to have no-export set to the other rs-clients (for whatever reasons. Some like it, some don't), then reserve another community for that, e.g. 16004:65281 and have customer use this community. Makes your life much easier imho ... Just my 0.02€ ... ymmv of course, Arnold -- Arnold Nipper / nIPper consulting, Sandhausen, Germany email: arnold@nipper.de phone: +49 6224 9259 299 mobile: +49 172 2650958 fax: +49 6224 9259 333
Hi Arnold,
actually I wouldn't do resp. interprete ist that way. If customer sets no-export, then simply do not export that prefix.
yes, what I didn't mention is that I've been asked to strip the no-export and then re-attach it...
If customer really wants to have no-export set to the other rs-clients (for whatever reasons. Some like it, some don't), then reserve another community for that, e.g. 16004:65281 and have customer use this community. Makes your life much easier imho ...
Thanks for the suggestion, I think from their point of view there should be no differences... I was anyway curious to know if my approach was correct and, possibly, try to fix it, otherwise we'll look for a workaround. Thanks, Simone. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
On Thu, May 20, 2010 at 04:41:04PM +0200, Simone Morandini wrote:
Hi all,
I need your help to understand what I'm missing... One of the rs clients sends a route with no-export community, so I have to strip it on ingress and re-attach it on egress. I thought I have two alternatives: using "interpret community no" in the bgp table of the peer, or playing with bgp_community.add and delete.
I don't understand why you want to strip and then reattach the no-export community and not just keep it attached all the time. BIRD internally interpret this community immediately before export to a BGP *protocol*, so it is not really important if the community is attached when the route is in the master table or going through pipes. If you attach the no-export community in the pipe export filter, then it is here before the export to the BGP protocol (MYPEER), therefore it wouldn't be exported unless the protocol has 'interpret communities no' set. If the BGP protocol has 'interpret communities no' set, it should export the route regardless of any communities, solely based on its export filter. If you have this option set to no (as you wrote) and still don't see the route on the other side, there is some problem. You could set 'debug { routes }' for the BGP protocol to see (in logs) if the route was really exported to the BGP protocol. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Hi Ondrej,
If you attach the no-export community in the pipe export filter, then it is here before the export to the BGP protocol (MYPEER), therefore it wouldn't be exported unless the protocol has 'interpret communities no' set. If the BGP protocol has 'interpret communities no' set, it should export the route regardless of any communities, solely based on its export filter. If you have this option set to no (as you wrote)
thanks for answering, now the problem is solved, it was my fault: I was applying the "interpret communities no" command in the wrong place... Simone. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
participants (3)
-
Arnold Nipper -
Ondrej Zajicek -
Simone Morandini