Two ports on one switch connected to each other

Unanswered Question
Dec 26th, 2007

Hello,

I'd like to rephrase a submission I made week, for which there were no replies... Does anyone know the STP ramifications when two ports on the same switch are connected to each other?

Thanks for any input.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 3.5 (13 ratings)
Loading.
Richard Burts Wed, 12/26/2007 - 13:33

Richard

I am not sure what was in your original post and why it did not receive any responses. But this question is almost straightforward and easy to answer.

The ramifications depend a bit on what options you may have configured on the ports. But in general if you connect 2 ports of the same switch together STP should detect the loop and should place one of the ports into blocking state.

If you have configured portfast on the ports STP should still detect the loop. Since portfast puts the ports directly into forwarding state there will be a flurry of activity as the ports loop until STP reacts and puts one port into blocking state. Note that in general you should configure portfast only on ports which you expect to be connected to end stations.

If you have configured the ports to disable Spanning Tree then the implications are that you will have a permanent loop.

HTH

Rick

Jon Marshall Wed, 12/26/2007 - 14:19

Hi Rick

In addition to Rick's post it does depend on whether you are running PVST+ or a single instance of spanning-tree.

If you are running a single instance or the 2 ports you connect together are in the same vlan then as Rick has pointed out that would be a loop and STP should block one of the ports.

However if the ports are in different vlans then there is no loop. Indeed this is the way you setup certain devices in bridge mode such as the 6500 Content switch module and the Firewall Services module where you have one IP subnet over 2 vlans and the CSM or FWSM bridges the two vlans together.

HTH

Jon

rickpastor@nort... Wed, 12/26/2007 - 15:35

Thank you Rick and Jon,

Yes, this is by design, similar to how you describe, Jon -- but as a failover mechanism for an IPS in in-line VLAN mode. The two ports will be in different vlans/subnets. The switch is running PVST+.

Do I understand correctly that

1) each of the two ports is getting a BPDU mistakenly believed to be for its own vlan, but is actually sent from a different vlan?

2) therefore, the lower-numbered (higher priority) of the two ports will be the DB for the segment (because root bridge, root path cost, and sending bridge id are all equal), and the other port will be blocking?

Thank you,

Rick

rickpastor@nort... Fri, 12/28/2007 - 09:27

I'd like to resubmit the above - maybe overlooked in all the submissions. If people like ratings, I'll be happy to rate all replies. Thank you very much.

Rick

Richard Burts Sat, 12/29/2007 - 19:30

Rick

I would like to suggest a somewhat different approach than just saying that you would like to re-submit this thread. You started with a very generic question which did not really describe your situation:

Does anyone know the STP ramifications when two ports on the same switch are connected to each other?

Instead of saying that you would like to have some more discussion I suggest that you think about what you really need to know and then initiate a new thread with a question that better reflects your environment and what you really need to know. You are more likely to get better answers to a well thought out question than you are to asking for more discussion of a not so well thought out question that has been in the forum for a while.

HTH

Rick

Jon Marshall Sun, 12/30/2007 - 10:32

Rick

Apologies for delay in replying, been away for a while.

Remember that because you are running PVST+ and that because each port is in a different vlan that it is not the same segment so both could end up being designated ports for their respecitve vlans. If one blocked and one forwarded for all vlans then the IPS/FWSM/CSM etc. would never pass traffic.

Jon

xcz504d1114 Sun, 12/30/2007 - 11:17

VLAN's aren't tagged on an access port, they are tagged on a trunked port, so if your ports are set as access ports all your doing is bleeding 2 subnets together.

Also if you have configured them for portfast, you might have BPDU guard and BPDU filter enabled, which means BPDU's are not going to be transmitted, and if they are transmitted the port will go into an error disabled state.

The only difference between the way BPDU's are sent in normal STP and PVST+ is that the BPDU's are transmitted on their respective VLAN across a trunked interface.

A BPDU packet itself does not contain VLAN information and it wont be tagged on the access port, and STP will block one of the interfaces.

Ramifications of bleeding multiple networks together are that you can spike CPU utilization and have packets being flood across your trunks multiple times. IE a PC in VLAN 1 sends a packet to another PC int eh same VLAN, the switches initial response is to flood any unknown destination out all ports except it's originating port, so it gets sent out the trunk of that switch for VLAN 1, but because you bled traffic into VLAN 2 as well the same packet will be flooded throughout every switch for VLAN 2 as well.

I hope that makes sense.

Any traffic that is destined for VLAN 1 will also be sent throughout VLAN 2, but the L3 info wont be routable on VLAN 2 if it's destined for another network. Also if Proxy arp is enabled on your router VLAN 2 could actually respond for VLAN 1's network and all traffic destined for other networks can possibly be sent inefficiently through VLAN 2.

I hope that helps you in your search. If you clarify what it is your actually trying to do we might be able to help you in a solution to your problem, bleeding VLAN's and tricking STP can potentially cause issues and problems in teh future for troubleshooting.

Craig

Jon Marshall Sun, 12/30/2007 - 11:56

Craig

That's a very good point in that VLAN's are not tagged on access ports so in effect your are bleeding 2 vlans together. I was primarily thinking of trunk links, which was a bit of a misleading assumption, but now i come to think of it perhaps you could shed some light on this.

We have a local director which is an old Cisco load balancer that bridges between two vlans with the same IP subnet ie.

The local director has two ethernet connections into the same 6500 switch. One of the ports on the 6500 is in vlan 180 and one is in vlan 171. As the local director is merely bridging between the 2 vlans and the ports are configured as access ports you would expect one of them to be blocked based on what you pointed out above and with which i agree with.

But they both show forwarding ie.

DC-BBP-F00-AS4> (enable) sh spantree 6/11

Edge Port: Yes, (Configured) Default

Link Type: P2P, (Configured) Auto

Port Guard: Default

Port Vlan State Role Cost Prio Type

------------------------ ---- ------------- ---- -------- ---- -----------------

6/11 180 forwarding DESG 4 32 P2P, Edge

DC-BBP-F00-AS4> (enable) sh spantree 6/12

Edge Port: Yes, (Configured) Default

Link Type: P2P, (Configured) Auto

Port Guard: Default

Port Vlan State Role Cost Prio Type

------------------------ ---- ------------- ---- -------- ---- -----------------

6/12 171 forwarding DESG 4 32 P2P, Edge

So i'm a little confused as to why one of these ports is not being blocked. It could be something to do with the local director itself i guess but documentation is not easy to find on this on Cisco's site.

Any ideas ?.

Jon

xcz504d1114 Sun, 12/30/2007 - 13:51

I apologize for answering Jon's question on your thread Rick :) I'll make a post to your latest response right after this one.

Jon,

I'm not to familiar with the Cisco Local director, but from my understanding it's about the equivalent of a bare bones PC in the form of a card. It works off NAT to load balance I believe, depending on which model you have I think they support appx 4 ports on the card. But like I said I'm not to familiar with its inner workings, I don't have any personal experience with one.

That being said, I would assume that this device doesn't pass BPDU packets, I understand it acts as a bridging device, but I don't think it acts as a straight pass through either. I've seen servers with misconfigured teamed NIC cards that act as pass throughs but I doubt that appliance forwards all packet information without discretion.

I guess to get an understanding of what's happening you could start with a show CDP neighbor command, if you see yourself then it's definately passing CDP information as a pass through. If not then you can assume it does filter some information. You can also try running a debug spanning-tree command and watch for BPDU's, they are sent out ever 2 seconds so you shouldn't have to watch very long.

Also I see port guard is enabled on the ports, are the ports in portfast? If so is BPDU filter also enabled? If so the ports aren't sending BPDU's anyways.

Craig

rickpastor@nort... Sun, 12/30/2007 - 12:52

I truly appreciate all the responses to this thread. As I stated at the beginning, this thread 'rephrased' a more complicated one that I had submitted a week before, but for which there had been no replies. I purposely introduced the simple thought of “STP ramifications… connected to each other” just to get some kind of response. I've only submitted once before to this forum and am somewhat unfamiliar with the customs.

Anyway, I was just finishing up the following illustration when Craig's response arrived:

One switch, two access ports, port 33-vlan 33; port 34-vlan 34 - ports connected to each other. Out port 33 is sent/forwarded a bpdu for vlan 33 with root bridge id (x), root path cost (n), sender bridge id (y) and a sender port id of 33. The switch doesn't know where the bpdu is headed, only that it is going out port 33 for vlan 33. In the meantime, the switch receives a bpdu on port 33 (actually sent from port 34). In that received bpdu is no indication of vlan, but the same root bridge id (x), root path cost (n), sender bridge id (y) as the bpdu sent out port 33. But the received bpdu has a sender port id of 34. The switch compares the two bpdus received on port 33. It doesn't know from where the bpdu was sent that it received on port 33, but does know that the bpdu has a higher (= lower priority) port id (34) than what it sent out port 33. Therefore, seeing the tie-breaker port id, the switch puts port 33 into Fwd state for vlan 33, making it the designated port for that segment.

Out port 34 is sent a bpdu for vlan 34 with root bridge id (x), root path cost (n), sender bridge id (y), and a sender port id of 34. The switch doesn't know where the bpdu is headed, only that it is going out port 34 for vlan 34. In the meantime, the switch receives a bpdu on port 34 (actually sent from port 33). In that bpdu is no indication of vlan, but the same root bridge id (x), root path cost (n), sender bridge id (y) as the bpdu sent out port 34. But the received bpdu has a sender port id of 33. The switch compares the two bpdus received on port 34. It doesn't know from where the bpdu was sent that it received on port 34, but does know that the bpdu has a lower (= higher priority) port id (33) than what was sent out port 34. Therefore, seeing the tie-breaker port id, the switch puts port 34 into Blk state for vlan 34, believing that the switch/port corresponding to the incoming bpdu is the designated port for the segment, since it has a lower port id.

As a result, port 33 is put into Fwd state for vlan 33, and port 34 is put into Blk state for vlan 34.

BTW, this is not an academic situation, but corresponds to recommendations made to our IPS team. They've had problems with the “interconnected ports as IPS failover” idea. That's why I'm trying to understand the mechanism. What's been recommended is to adjust the port cost of one of the two ports (33 or 34 in the above example), before the actual IPS (trunk on port 32) is activated.

Perhaps the whole thing makes more sense if we just make the failover ports (33 and 34) trunks instead of access ports. In the meantime, I will read Craig's and Jon's submissions more carefully.

Thanks again.

Rick P.

xcz504d1114 Sun, 12/30/2007 - 14:08

Putting them in trunk ports doesn't do much for you either, all that does is give PVST+ a chance to send the BPDU's on their respective VLAN's.

The ports did exactly what they should do.

So, is the problem that one of the ports is going into a blocking state?

If so then just put the access ports in portfast and enable BPDU-filter. This will prevent both ports from sending BPDU's and they will both be forwarding.

I don't know if you had considered it, but setting the switch to be the "root" switch for those VLAN's under the assumption that the root has all ports in a forwarding state will no work, this is the one situation where the root switch will put a port into a blocking state.

To enable bpdu-filter on catos issue

set spantree portfast bpdu-filter [mod/port] enable

On IOS,

in global config enter

spanning-tree portfast bpdufilter default

Then on the interface enter

spanning-tree portfast

Doing this also places BPDU filter on all access ports running in portfast.

Alternatively, in IOS you can enable the filter on individual ports without placing them in portfast by using the

spanning-tree bpdufilter enable

command in the interface desired.

You said they were having problems with the interconnected ports, what kind of problems are they experiencing?

Aside from the port being blocked, what issues are you also trying to alleviate/work around?

rickpastor@nort... Sun, 12/30/2007 - 15:22

Here's where it gets a little cloudy. The IPS team has asked for input, but are not completely sure what's been recommended to them or why. As illustration, what we have is an in-line vlan IPS connected via trunk to switch port 32, with ports 33 and 34 (both access ports) to be used for failover. (Since you mentioned it, this is in fact a root bridge for both vlans, and the 'all ports in fwd state' idea did help muddle my brain on this - thanks for clearing that up.)

Anyway, to keep this from turning into a bigger topic than it started out as (and thereby trying the patience of my mentors here), I'd like to just simplify my request, and then think over some the suggestions you've given thus far, to both me and to Jon, who seems to have a similar issue.

So to morph this a little… given your substantiation of the 2 interconnected access ports/2 vlans behavior, the adverse effects of which you also expanded to include the bleeding vlans effect, can I ask how this idea doesn't also apply to the IPS trunk itself?

In other words, given the 'tie-breaker' port cost/priority that designates one port as forwarding and one as blocking, how does the IPS in-line vlan trunk resolve this itself? In this case, when bpdus are sent out both vlans of the trunk (and feeding back to itself, after going through the IPS) not only are root bridge, root path cost, and sender bridge id the same, but also, the port priority is the same too. In this case it is a complete tie … I previously had to resolve to myself that in this special case the trunk is forwarding for both vlans. But is this in fact the case?

Of course, for the IPS trunk, we do want forwarding on both vlans. So if they are not forwarding, I'll make sure they are. You've already given some good suggestions indirectly in your responses to Jon, i.e. 'sh cdp, and 'debug spanning-tree', to help determine how the IPS is affecting the bpdus, and whether bpdus are even being sent. I'll assume that your suggestions re: portfast and bpdu-filter apply only to access ports, not to trunks....

So at this point, I'll be happy to learn whether and how the IPS in-line vlan trunk affects bpdus sent to it. On the other hand, if the 'complete bpdu tie' situation is a special case where the switch just puts the trunk in forwarding state for both vlans, then the IPS presence is a non-issue.

Having learned the answer to this, I'll save for another thread the question of why in the heck adjusting the port cost for the aforementioned ports 33 and 34 should have any effect on whether those port is forwarding (which is what our IPS team seems to think) - again, this is for another thread. I've had to take a step backwards here…

Thanks again, very much, for your patience and help.

Rick P.

xcz504d1114 Sun, 12/30/2007 - 17:14

Quite honestly, I can't wrap my mind around the interconnected ports. I'm trying to justify logically the benefit of that and how it actually provides a fail over. I have to be missing some part of the logic there.

What I've assumed so far is that you are bleeding the VLAN's into each other to ensure all the traffic goes through the IPS in case of some type of failure? But I can't grasp what kind of failure that could be.

The bleeding affect wouldn't happen with just the IPS, if the IPS is capable of talking to a trunked interface (probably 802.1q) then it is already familiar with the tagging process and will keep the traffic seperate. However with the interconnected ports like that it could recieve 2 copies of the same frame from both VLAN's.

So when VLAN 33 sends out a BPDU based on PVST+ rules, it sends it out tagged for VLAN 33, the end device recieves this BPDU and does whatever it needs to, since the BPDU had no destination address, that packet doesn't need to go anywhere and the IPS just discards it.

The IPS doesn't route traffic anyways, all it is doing is receiving a copy of the information contained on the Trunk, it doesn't send it back out, it just accepts the packet, does it's analyzing or whatever and is done with that packet. Much like placing a port into a SPAN state.

Portfast should only be placed on access ports, depending on what version of IOS you are running it will probably even give you a warning message about that when you enable portfast, bpdu-filter globally will enable bpdu-filter to be ran on all ports in portfast (again trunks should not be in portfast). Essentially putting bpdu-filter on an interface removes from STP.

Because the trunk to IPS isn't a redundant link both VLAN'S will be in a forwarding state.

Changing the port priority won't fix the problem either, it will still do the standard negotiation and one port will go to blocking.

HTH

Craig

xcz504d1114 Mon, 12/31/2007 - 09:25

Rick,

Looking over that document, I can see how traffic might not be shaped the way you want it to be.

So it seems that your IPS is acting as a VLAN "router" I guess is a simple way to describe it. It takes a packet destined for the server, but the workstations and servers are on seperate VLAN's, so it merely routes the traffic to the other VLAN for the PC.

Personally, I feel a router would be a better option in this case, or a L3 switch.

Given what I know about how the device is working now, running a routing protocol is the only thing I can think of that would be that dynamic, STP is a great redundancy protocol, but using it like that I don't think you will get the results you are looking for.

The way you have it setup right now, STP has no way to detect a problem with the IPS and reconverge the network, I think your best option to ensure the packets are both routed properly and have the ability to failover is to use a router.

Have the IPS connected to the router which is connected to teh switch, trunk the inter face from the switch to the router and then the interface to the IPS is also trunked, if the IPS link fails the router still knows how to get to VLAN 33. You will have to adjust the route paths a little bit manually, but ultimately I think it would work much better than the STP option.

There is no concievable way to have STP manipulate ports 33 and 34 in the way you are looking to do. Since the ports are access ports, no VLAN information is passed so the switch does not see them independant VLAN's, it jsut sees the BPDU information and sees it as a loop. Putting them into trunked interfaces also does not help your situation because as a packet leaves port 34 on vlan 34, it has no way to get to VLAN 33.

HTH

Craig

rickpastor@nort... Mon, 12/31/2007 - 13:36

Thanks Craig,

Having looked now into the agreed-upon implementation here, it looks as though they're interested in keeping the failover ports both forwarding, which seem to me will cause mac addresses flapping between ports, meaning half the packets won't be inspected by the IPS. I don't yet know how they justify this reasoning, and plan on reading up on some published deployment scenarios.

If it comes to where routing is necessary, then that's what we'll do. I appreciate your suggestions on this. Assuming I reach a resolution at some point, I'll publish it in this thread. Thanks to you, Jon, and Rick for your contributions.

Happy new year

Rick P.

xcz504d1114 Thu, 01/03/2008 - 06:24

I talked to one of the guys I work with today about it to see if it made sense to him. It didn't, we both agreed that you will see duplicate traffic, and most likely the IPS will not even be used after the switch establishes it's path it wants to use. Or by some stroke of luck you will actually have all your traffic going through the IPS, it will be determined by which interface recieves the returning frame last.

He did however mention that he had heard somethign when he went through his CISSP course about the IPS having an ability to shunt different ports open and closed, essentially lettign the IPS control the ports in a way, but I couldn't find anything about that specifically.

Good luck with your setup.

Craig

Actions

This Discussion