You're trying to keep routes learned from a router from being reflected to a router on the same subnet? I'd probably do this with a community--set a community on the routes for any given subnet, and then block the reflection back out using a route map with a community list in it.
I'm not certain, though, that this is really what you want. It sounds more like you don't want the traffic to go through the hub--the routes still need to get between the route reflector clients, right? If so, you might try setting next-hop self on each of the route reflector clients, so the next hop is set all on the same subnet. BGP will install routes it learns from the reflector in the local table with the next hop set on the same subnet, which should resolve to a direct hop.
I would actually think this is already happening, since the IGP should show the next hop as being reachable through the common subnet, rather than through the reflector, unless you're setting next hop self on the reflector for some reason?
Actually, what I wanted was for the route-reflector clients to only install routes from the other route reflector clients.
Since the topology is dual-hub and spoke, there was no point installing 90% of the IBGP routes since they were all reachable via the hubs anyways which happen to be originating a default route. In other words, the only IBGP routes that are actually useful at the access-layer are those that come from other access routers in the same subnet.
I went and configured a community list on the access-routers and then filterred the advertisements from the reflectors. It's working fine.
I just wanted to make sure there wasn't a single command I could type on the reflectors to only reflect routes between clients to save some time.
However, given that the advertisement policy was consistent throughout the access layer I was able to quickly implement the migration by creating a single script file and pasting it in to each of the 20 routers along with a soft-reconfig clear. Painless.
[toc:faq]The ProblemOn traditional switches whenever we have a trunk
interface we use the VLAN tag to demultiplex the VLANs. The switch needs
to determine which MAC Address table to look in for a forwarding
decision. To do this we require the switch to do...
[toc:faq]Introduction:Netdr is a tool available on a RSP720, Sup720 or
Sup32 that allows one to capture packets on the RP or SP inband. The
netdr command can be used to capture both Tx and Rx packets in the
software switching path. This is not a substitut...
IntroductionOSPF, being a link-state protocol, allows for every router
in the network to know of every link and OSPF speaker in the entire
network. From this picture each router independently runs the Shortest
Path First (SPF) algorithm to determine the b...