[rspan in 'hub+spoke' topology]

Question

Hi,
I have the topology depicted in the attached drawing.
What we want to achieve is to enable rspan to replicate monitored traffic from access switches (3550 spokes) to a core switch (6500 hub).
The configuration in general is working and looks like this:
HUB:
monitor session 1 destination interface Gix/y
monitor session 1 source remote vlan z
SPOKES:
monitor session 1 source interface Gix/y
monitor session 1 destination remote vlan z
As stated previosly the environment is working, but...we're having one problem. The uplinks from the spokes to the hub are almost full. After doing some troubleshooting, we found that span traffic is being replicated by the hub to the spokes. The reason I say this is that when i remove the rspan vlan (on the core switch) from the uplink to the hubs the output traffic from core to access (or input on the access switches) goes down in the same amount being received by the network analyzer. when i add the vlan on the uplink trunk again, the traffic going out of the core to the access switches goes up by the same amount being sent to the network analyzer.
Like i said, the rspan part seems to be working fine, but the uplinks to the access switches are getting full because the hub switch is copying the span traffic to all uplinks which is not what we want.
Two questions here:
1.- Is this the way rspan is supposed to work in this environment?
2.- if not, is there a way to turn off this behavior or does it sound like a bug to you?
Thanks in advance!
c.

Answer 1

Hello,
in Hub and Spoke - as in any other L3VPN - traffic will flow in the opposite direction of IP routing updates. In a Hub and Spoke setup the spoke sites should get routing updates from the hub site. Thus one faces a split horizon problem: updates learned at the hub CE from a neighbor (PE) will not be sent back over the same interface to that neighbor. Hence the simple solution is: one VRF and interface to announce spoke routes from the PE to the hub CE and another interface terminating in a second VRF to announce the routes from the hub CE back into the MPLS VPN environment.
Just as a side note: this results in an unusual load pattern on the two hub CE interfaces. Both interfaces will have nearly only load in one direction.
Hope this helps! Please rate all posts.
Regards, Martin