Dan Carp
asked on
Aggregate Wireless PTP LInks
Brief - is it possible to aggregate two wireless PTP links in order to double throughput and potentially reduce latency between locations?
We have two pairs of wireless point to point links (Cambium PTP600) configured from one building to another. Both pairs are connected to HP Procurve V1910 switches. On both switches, I've created dynamic bridge aggregation interfaces with two selected ports. (Possible side note - I have also configured BAGG1 as either Trunk or Hybrid link type with no effect on the connection.)
When I plug the devices into the aggregated ports, the status of both member ports shows as "Selected". However, the connection still seems to be operating via only one of the two PTP links. The throughput nor latency are affected (exactly the same as when only one PTP link is connected). If I pull one of the links, the connection does cut over to the other link after about 30 seconds so there does appear to be fault tolerance. And lastly when all four Cambium devices are plugged into aggregated switches, I lose HTTP management access to three of the four (and it's restored when I unplug any one of them).
Does it sound as though I am not configuring the switches properly or is there something about wireless PTP links that would prevent them from configuring in the same way wired links would? Thanks very much in advance!
We have two pairs of wireless point to point links (Cambium PTP600) configured from one building to another. Both pairs are connected to HP Procurve V1910 switches. On both switches, I've created dynamic bridge aggregation interfaces with two selected ports. (Possible side note - I have also configured BAGG1 as either Trunk or Hybrid link type with no effect on the connection.)
When I plug the devices into the aggregated ports, the status of both member ports shows as "Selected". However, the connection still seems to be operating via only one of the two PTP links. The throughput nor latency are affected (exactly the same as when only one PTP link is connected). If I pull one of the links, the connection does cut over to the other link after about 30 seconds so there does appear to be fault tolerance. And lastly when all four Cambium devices are plugged into aggregated switches, I lose HTTP management access to three of the four (and it's restored when I unplug any one of them).
Does it sound as though I am not configuring the switches properly or is there something about wireless PTP links that would prevent them from configuring in the same way wired links would? Thanks very much in advance!
However, the connection still seems to be operating via only one of the two PTP links. The throughput nor latency are affected (exactly the same as when only one PTP link is connected).That would be normal. When you aggregate two links, traffic from a single flow (an FTP transfer, for example) will use only one of the links. But other flows could use the other links.
If I pull one of the links, the connection does cut over to the other link after about 30 seconds so there does appear to be fault tolerance.That does not sound like you have the trunk setup. That sounds like spanning-tree behavior. Which means that all traffic is using only one link.
Can you post the configs of the two switches and indicate which ports are connected to the Cambium devices?
ASKER
Thank you both for your comments. I am attaching config files for both switches. The aggregate port in use is BAGG1 which is mapped to 1/0/23 and 1/0/24 (same config on both switches). The one device that remains controllable is attached to port 1/0/23 of the .202 switch.
@rharland2009 - I believe that the devices do support LACP. I've attached a couple of excerpted pages from the user guide, but I believe the relevant text is:
.202NEW---startup.txt
PTP600-User-Guide-Extract.pdf
@rharland2009 - I believe that the devices do support LACP. I've attached a couple of excerpted pages from the user guide, but I believe the relevant text is:
The PTP 600 Series is transparent to layer two control protocols (L2CP) including:.192NEW---startup.txt
• Link aggregation control protocol (LACP)
.202NEW---startup.txt
PTP600-User-Guide-Extract.pdf
I'm not sure what your bridge-aggregation interface is. Whenever I've done this, I use the trunk command.
For example:
trunk g1/0/1, g1/0/3 trk1 lacp
What do you see when you issue a "show span vlan 617"? Does it show one of the ports as blocking?
For example:
trunk g1/0/1, g1/0/3 trk1 lacp
What do you see when you issue a "show span vlan 617"? Does it show one of the ports as blocking?
ASKER
Apologies for the following question, but where would I input such commands? When not using the GUI (my tool of choice), I access the switch via SSH along with the extended command set here:
http://h30499.www3.hp.com/hpeb/attachments/hpeb/itrc-269/30228/1/user_mode_cli.txt
I've understood that this is a mirror of the commands available when connecting via console port, but are there more via console that I'm not aware of? Though based on a Google search, those may be Cisco commands and I can't seem to find the HP equivalents. Thanks again!
http://h30499.www3.hp.com/hpeb/attachments/hpeb/itrc-269/30228/1/user_mode_cli.txt
I've understood that this is a mirror of the commands available when connecting via console port, but are there more via console that I'm not aware of? Though based on a Google search, those may be Cisco commands and I can't seem to find the HP equivalents. Thanks again!
I was assuming that the 1910 used the same UI as other HP switches that I've worked on.
But in looking at a manual for the 1910, that doesn't appear to be the case.
According to this document, it looks like configuring a trunk is done through the GUI only (page 226) since they have no mention of the CLI commands used.
Usually (at least on the HP Procurve switches I've configured), anything you can do from the console, you can do over telnet or SSH. And there are some tasks that can't be done through the GUI and must be done from the CLI.
This switch appears to be the exception.
But in looking at a manual for the 1910, that doesn't appear to be the case.
According to this document, it looks like configuring a trunk is done through the GUI only (page 226) since they have no mention of the CLI commands used.
Usually (at least on the HP Procurve switches I've configured), anything you can do from the console, you can do over telnet or SSH. And there are some tasks that can't be done through the GUI and must be done from the CLI.
This switch appears to be the exception.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks craigbeck for all of the info - very useful! I've currently got the PTP600s connected to the switches without utilizing the bridge so that I retain HTTP access to both. STP is doing it's job as there's no bridge loop and failover is working (albeit after about 30 second delay, which I presume is normal).
Layer 3 is new to me so I apologize for the lack of knowledge here. I've done some research and understand that it's about IP routes and VLANs. Could you explain in broad terms how this configuration would work? I presume I'd set up a new VLAN (different VLANs for both pairs of PTP600's?), assign each switch an additional new IP address within a new subnet, assign the VLAN to the new IP address, then bridge the VLANs at the switch (or router?) level. With a layer 3 approach, are you suggesting we'll be able to achieve link aggregation (though perhaps not technically termed as such)?
(Side note - since our switches are layer 3 capable, would we see much benefit running even our wired gigabit connections via layer 3 or is the improvement minimal for a small office (~45 people)?)
Thanks very much for your help so far, and to all, a very happy and healthy New Year!
Layer 3 is new to me so I apologize for the lack of knowledge here. I've done some research and understand that it's about IP routes and VLANs. Could you explain in broad terms how this configuration would work? I presume I'd set up a new VLAN (different VLANs for both pairs of PTP600's?), assign each switch an additional new IP address within a new subnet, assign the VLAN to the new IP address, then bridge the VLANs at the switch (or router?) level. With a layer 3 approach, are you suggesting we'll be able to achieve link aggregation (though perhaps not technically termed as such)?
(Side note - since our switches are layer 3 capable, would we see much benefit running even our wired gigabit connections via layer 3 or is the improvement minimal for a small office (~45 people)?)
Thanks very much for your help so far, and to all, a very happy and healthy New Year!
If you're using STP 30s is about right. You'll be sending traffic over one link only and the other will just be sending BPDUs at intervals.
With Layer-3 links you'd have separate routed links which could be used at the same time. The advantage of using Layer-3 links is that you're not sending broadcast (unwanted in most cases) traffic over the wireless links which can reduce throughput. In busy networks this can be a huge problem, especially on large broadcast domains. If you go Layer-3 you create two separate broadcast domains (one each side of the bridges).
All you'd really need to do is configure two routed interfaces on each switch and connect the bridges. Each link would be its own /29 (for example to allow for management of the radios too). You'd have a VLAN (or VLANs) at each side for your clients.
With Layer-3 links you'd have separate routed links which could be used at the same time. The advantage of using Layer-3 links is that you're not sending broadcast (unwanted in most cases) traffic over the wireless links which can reduce throughput. In busy networks this can be a huge problem, especially on large broadcast domains. If you go Layer-3 you create two separate broadcast domains (one each side of the bridges).
All you'd really need to do is configure two routed interfaces on each switch and connect the bridges. Each link would be its own /29 (for example to allow for management of the radios too). You'd have a VLAN (or VLANs) at each side for your clients.
ASKER
I'm following most of the way. Only piece I'm not 100% sure about in this setup is where the VLANs are set to communicate with each other. Right now, most of our devices are on VLAN 1. We also have VLAN 6 setup for IP phone traffic. All switch ports have untagged membership with 1 and tagged for 6. Currently the VLANs communicate with each other via two interfaces and policy set on our gateway.
If I create a VLANs for each pair of devices and place them on their own subnets (e.g. VLAN 20 for one pair with subnet 192.168.20.x and VLAN 30 for the other pair with subnet 192.168.30.x), is the link between the VLANs/subnets achieved via IPv4 routing at the switch level? This is where I get a bit lost - how to tie these new VLANs/subnets back to our existing VLANs.
Again - my apologies for asking these perhaps simple questions. Learning about networking on the job and have looked for guides, but not found a clear one. Thanks very much again for the assistance!
If I create a VLANs for each pair of devices and place them on their own subnets (e.g. VLAN 20 for one pair with subnet 192.168.20.x and VLAN 30 for the other pair with subnet 192.168.30.x), is the link between the VLANs/subnets achieved via IPv4 routing at the switch level? This is where I get a bit lost - how to tie these new VLANs/subnets back to our existing VLANs.
Again - my apologies for asking these perhaps simple questions. Learning about networking on the job and have looked for guides, but not found a clear one. Thanks very much again for the assistance!
The VLANs will not extend over the two sites if you do layer-3 links.
If you need the same VLANs in both sites, you will need to do layer-2 links.
If you need the same VLANs in both sites, you will need to do layer-2 links.
ASKER
Thanks Don! Trying to wrap my head around the topology...
Current setup:
Main branch - Data (VLAN 1, Subnet .1.x), Phones (VLAN 6, Subnet .6.x)
Links - Operate/Managed (VLAN 1, Subnet .1.x), transparent to tagged VLAN traffic
Remote branch - Data (VLAN 1, Subnet .1.x), Phones (VLAN 6, Subnet .6.x)
If I understand correctly, you're suggesting that to use Layer 3, we would do this:
Main branch - Data (VLAN 1, Subnet .1.x), Phones (VLAN 6, Subnet .6.x)
Link 1 - Operate/Managed (VLAN 20, Subnet .20.x)
Link 2 - Operate/Managed (VLAN 30, Subnet .30.x)
Remote branch - Data (VLAN 2, Subnet .2.x), Phones (VLAN 7, Subnet .7.x)
I get lost where the VLANs communicate with each other so that traffic on VLAN 2 would speak transparently with VLAN 1.
Again - very sorry for what feel like rudimentary questions. I don't have much experience with IP Routing so am figuring this stuff out on the fly. Appreciate very much the help!
Current setup:
Main branch - Data (VLAN 1, Subnet .1.x), Phones (VLAN 6, Subnet .6.x)
Links - Operate/Managed (VLAN 1, Subnet .1.x), transparent to tagged VLAN traffic
Remote branch - Data (VLAN 1, Subnet .1.x), Phones (VLAN 6, Subnet .6.x)
If I understand correctly, you're suggesting that to use Layer 3, we would do this:
Main branch - Data (VLAN 1, Subnet .1.x), Phones (VLAN 6, Subnet .6.x)
Link 1 - Operate/Managed (VLAN 20, Subnet .20.x)
Link 2 - Operate/Managed (VLAN 30, Subnet .30.x)
Remote branch - Data (VLAN 2, Subnet .2.x), Phones (VLAN 7, Subnet .7.x)
I get lost where the VLANs communicate with each other so that traffic on VLAN 2 would speak transparently with VLAN 1.
Again - very sorry for what feel like rudimentary questions. I don't have much experience with IP Routing so am figuring this stuff out on the fly. Appreciate very much the help!
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
OK - now I think I'm following, and if I'm accurate, then Layer 3 may not work for us. The point of the wireless link setup is that it would serve as close to the same function as running an ethernet cable from the switch in one building to the switch in the other. We have the two pairs of devices to try to make the connection more robust, with hopes of increasing throughput but at very least reducing congestion over a single link.
All workstations need to be able to access the same set of central servers, and all phones need to be able to contact all other phones. They don't necessarily need to be on the same VLAN if there is a benefit to this configuration in regard to network quality. But ultimately, somewhere in the topology, the VLANs WOULD need to communicate with each other, and it sounds like the place to connect VLAN traffic is all the way up at the gateway level. Do I understand correctly that you can't (or wouldn't want to) connect VLAN traffic at the managed switch level?
All workstations need to be able to access the same set of central servers, and all phones need to be able to contact all other phones. They don't necessarily need to be on the same VLAN if there is a benefit to this configuration in regard to network quality. But ultimately, somewhere in the topology, the VLANs WOULD need to communicate with each other, and it sounds like the place to connect VLAN traffic is all the way up at the gateway level. Do I understand correctly that you can't (or wouldn't want to) connect VLAN traffic at the managed switch level?
It all comes down to whether or not the phones and other devices have to be on the same VLAN. If they don't, make the inter-building links layer-3.
If they do, then make the links layer-2.
If they do, then make the links layer-2.
The loss of management access when you have all four devices plugged in is strange, and hints at spanning-tree or some other loop-detection mechanism - although it's hard to tell without more detail.