Hi Saku, thank you for answering. Just to clarify things a bit, Juniper configuration says basically this:
Every route advertised (vpnv4) for VRF A, has SoO 100:1 (alongside RTs, of course). Every route advertised (vpnv4) for VRF B, has SoO 100:2 Every route advertised for VRF C, has SoO 100:3 etc. Now, it's also should be mentioned that JunOS CLI does this within the export declaration section, meaning every vpnv4 route exported will have this communities with 1 CLI command. As far as Cisco is concerned, I do not have the per-neighbor SoO command available. And besides, it does a slightly different thing – it attaches a SoO for every route exported from every VRF. Meaning it alters the current (JunOS) behavior, forcing some changes to be done on downstream routers matching the current values of SoO. I did not mentioned that above, I did tried a simple outbound route-map, though (never mind it suffers the same flow as above) but (taken from 7200VXR, probably will be the same on Cat6500): R3.111(config)#route-map SOO_OUT R3.111(config-route-map)#set extcommunity soo 111:1 R3.111(config-route-map)#exit R3.111(config)#router bgp 111 R3.111(config-router)# address-family vpnv4 R3.111(config-router-af)# neighbor 1.1.1.1 route-map SOO_OUT out % "SOO_OUT" used as BGP outbound route-map, set extcommunity soo not supported Hopefully this resolves anything unclear in my previous message. Any idea will be welcomed. Best Regards, Alex On Tue, Jul 10, 2012 at 4:25 PM, Saku Ytti <s...@ytti.fi> wrote: > On (2012-07-10 14:28 +0300), Alex K. wrote: > > > I've tried vrf export-maps (did nothing as long as SoO is concerned), per > > neighbor SoO is not available. > > > > So the question is, will somebody here can come up with a trick to > > replicate JunOS behavior in a Cisco environment? > > Your question is bit ambiguous, but I'm giving it a shot. > > You are using IOS's BGP neighbour statement 'soo' syntactic sugar, which > essentially does two things > > a) sets SoO for routes received from that neighbour > b) stops advertising routes to that neighbour, if they have that SoO > > Before IOS had this syntactic sugar, you'd do it like this > > neighbour foo route-map in FOO-IN > neighbour foo route-map out FOO-OUT > > route-map FOO-IN permit 100 > set ext-community soo:42:42 > route-map FOO-OUT deny 100 > match ext-community SOO42 > route-map FOO-OUT permit 200 > > > This latter example works the same way in JunOS. For each neighbour in > import policy-statement you set target community and in export > policy-statement you match for that target community and reject routes. > > -- > ++ytti > _______________________________________________ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/