We would like to pass traffic tagged (in the same vlan) from Router_1 to Router_2 throught a Traffic Management device (in transparent mode). Now, we are using two switches (running and aimed config Link below) but we would like to remove one of our old switches and use only our Cisco 6509 switch.


We are thinking about using Bridge Groups (BVI) but we are not 100% sure if it would work. Any idea or suggestion before we start bridge group configuration on the Cisco 6509 Switch.

  • What exact linecards you have and supervisor (show module). The 'transparent mode', does it keep MAC addresses unchanged, so does Router1 see SMAC of Router2 or SMAC of 'Traffic Management Device'
    – ytti
    Jul 12 '13 at 10:11
  • @user2028 what supervisor and ios do you have?
    – This
    Jul 12 '13 at 12:54
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can post and accept your own answer.
    – Ron Maupin
    Jan 4 at 23:33

If all traffic needs to go from gi0/4 to gi0/3 and from gi0/2 to gi0/1 you could use layer 2 local switching. Configuration would be about:

connect Router1-TM GigabitEthernet0/4 GigabitEthernet0/3 
connect Router2-TM GigabitEthernet0/1 GigabitEthernet0/2

If your linecards do not support layer 2 local connect, then consider bridge-groups:

bridge irb
interface range GigabitEthernet0/4 , GigabitEthernet0/3
 bridge-group 1
interface range GigabitEthernet0/1 - 2
 bridge-group 2
bridge 1 protocol ieee
bridge 1 priority 128
bridge 2 protocol ieee
bridge 2 priority 128

However I'm dubious if bridge is actually in PFC, not at least up-to PFC3, I'm not sure about PFC4 (SUP2T).

Finally you have option to use QinQ:

interface range GigabitEthernet0/4 , GigabitEthernet0/3
 switchport access vlan 42
 switchport mode dot1q-tunnel
 switchport nonegotiate
interface range GigabitEthernet0/1 - 2
 switchport access vlan 43
 switchport mode dot1q-tunnel
 switchport nonegotiate

In this option VLAN 123 that comes from Router1, gets VLAN 42 on top of it [ 42 123 ], MAC addresses from ALL Router1 VLANs are populated in VLAN 42 mac-address-table. So then MAC lookup is done against VLAN 42 where we only have traffic-manager, once we send the frame out to traffic-manager, we pop VLAN 42 out.
Now after traffic manager send it OUT, again in VLAN 123, it gets VLAN 43 on top of it [ 43 123 ], and as previously MAC lookup is done for table 43, where we only have Router2, frame is sent out towards Router2 and VLAN 43 is popped out.

By default STP is not tunneled like rest of the traffic, but STP BPDU is directly visible to the switch, and switch will react to it normally, this is often undesirable. If STP BPDU needs to be tunneled as well you need feature called 'Layer 2 Protocol Tunnel' or L2PT.
L2PT is fancy word for DMAC address rewrite, when incoming frame has DMAC identifying the frame as special BPDU, such as STP, you rewrite the DMAC to some non-special address, for STP BPDU DMAC is written ingress to 01-00-0c-cd-cd-d0 then in egress the 01-00-0c-cd-cd-d0 DMAC id again rewritten back to STP DMAC.
Configuration is as follows:

 l2protocol-tunnel cdp
 l2protocol-tunnel lldp
 l2protocol-tunnel stp
 l2protocol-tunnel vtp

You can use 'show l2protocol-tunnel interface giga0/1' to see counters for both directions of the MAC rewrite 'encap' means real DMAC was written to 01-00-0c-cd-cd-d0 and 'decap' means 01-00-0c-cd-cd-d0 was written back to real DMAC.

switch#show l2protocol-tunnel  interface giga1/0/6
COS for Encapsulated Packets: 5

Port       Protocol Shutdown  Drop      Encapsulation Decapsulation Drop
                    Threshold Threshold Counter       Counter       Counter
---------- -------- --------- --------- ------------- ------------- -------------
Gi1/0/6    cdp           ----      ----       2674827        263832            0
  • I specially like third option. We have SUP720, and linecards X6748. Could be any STP problem related?
    – RS1983
    Jul 12 '13 at 10:33
  • There is no loop in your topology, so no STP issues. However STP is NOT forwarded anymore, so if you have really L2 loop in the topology just not shown in given diagram, STP is broken. I'll add fix to the answer.
    – ytti
    Jul 12 '13 at 10:43
  • I see it clear. I will report with results!
    – RS1983
    Jul 12 '13 at 11:15
  • I have not fully parsed the technical reasons for why you're recommending option 1 or 2, but if you could even configure such crazy stuff on the Sup720 both of those stand a 90% chance of forcing IOS to punt all those packets to the CPU
    – This
    Jul 12 '13 at 11:47
  • 1
    We regularly run #1 in production, if interfaces support it, it's fully in HW. Bridge-group may be useless suggestion for 6500/7600, I'm not sure if that has changed in PFC4.
    – ytti
    Jul 12 '13 at 11:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.