Wired Intelligent Edge

Hi there,

 

I have 3 Aruba 2930F switches (1 x 28-port and 2 x 48-port).

 

I have configured all the switches with the same configuration (see attached). the only differences being the model, no. of ports,switch name and the ip addresses for each switch on the 2 vlans.

 

I have had the 2 48 port switches running on the network for a number of weeks now and I have been getting regular "Warnings and Info" entries in the log for the following;

 

1) Port "x" PD MPS Absent Indication

2) Port "x" is now offline. followed by Port "x" blocked by STP, followed by Port "x" is now online. - Where "x" is the same number in all of the notifications. This is happening for multiple ports? Am I correct this has something to with the switch not being able to "initially" detect the end-point device?

3) Port "x" PD MPS Absent Indication - the switch no longer detects a device on port "x". Device has been disconnected, powered down or stopped functioning.

The above is happening on all of the switches for different ports.

 

Some further info...

 

1) I can ping all the switches on each of their assigned vlan IP addresses. The only exception is the switch zeus (10.1.0.23/10.1.1.5) but I am pretty sure this is because the cable has been removed which links it to the network so not too concerned about that just yet.

2) I can connect to all the switches via web gui and putty (telnet) with the exception of zeus (10.1.0.23/10.1.1.5 and 10.1.0.14/10.1.1.3). as mentioned before ignore the 10.1.0.23 device for now as it isn't connected to the network. I am stumped by not being able to connect to the 10.1.0.14 switch because i know for a fact the server I'm logging into is connected directly to it so it is obviously working, I just can't connect via the webgui or putty (telent).

 

My real query here though is.... what is the best way to connect these switches together. Refer to attached diagram, My intention is to have one connection going from each switch to 10.1.0.23 (intended "Core switch") so there will be an uplink to each of these switches rather then daisy chaining the switches together... from what I've read daisy chaining is not recommended.

 

If you have any thoughts on the configuration file, network design and potential improvements, recommendations on making things better that would be appreciated.

 

Thanks,

 

 

Are you sure you dont have a link connected between any of the 3 edge switches? This could be a genuine STP event. If you run the command "show lldp i r" from each of the 3 edge switches what output do you see? Also what is the output of "show span"?

 

The way you have the switches connected in the diagram is Ok except it doesnt provide any redundancy for uplink failure. You could connect edge 1 & 3 to 2 and let STP (assuming configured correctly) block these links under normal opperation. Then if an uplink fails STP will reconverge and unblock the relevant port.

I have reviewed the port configs on the 3Com switch which is the core switch for the network and discovered that some of the ports weren't configured for both VLANs. I moved the connections to ports which I reconfigured for both vlans. I ran show lldp i r prior to this but forgot to save the output in the text file. Now that the connections have been moved here is the output from show lldp i r.... I am pretty sure the output is different from the first time I ran show lldp i r  as there are fewer entries but I am still not able to connect to the 10.1.0.23 switch. I need to go to the client site and check the switch physically.

 

10.1.0.14
 
 LLDP Remote Devices Information

  LocalPort | ChassisId          PortId             PortDescr SysName
  --------- + ------------------ ------------------ --------- ------------------
  6         | 00 23 24 cf 4d 5a  00 23 24 cf 4d 5a
  23        | 00 23 24 f9 f8 0f  00 23 24 f9 f8 0f
  40        | e0 4f 43 5a 61 08  e0 4f 43 5a 61 08
 
10.1.0.20

  LLDP Remote Devices Information

  LocalPort | ChassisId          PortId             PortDescr SysName
  --------- + ------------------ ------------------ --------- ------------------
 
10.1.0.21
 
 LLDP Remote Devices Information

  LocalPort | ChassisId          PortId             PortDescr SysName
  --------- + ------------------ ------------------ --------- ------------------
  25        | MOFA_DIST_SW01     GigabitEthernet0/3 

 

The switch connection under 10.1.0.21 is a switch in another rack connecting all the servers to the network, I am pretty sure there is only 1 connection going from this switch to the switches in the other rack but I suspect that this is "daisy-chained" to one of the downstream switches rather than the core switch so will need to check that as well.

 

Any insight on the above would be appreciated.

 

Thanks,

I will review the above but when you say you cant connect to 10.1.0.23 are you doing this remotely? Via VPN? What if you first SSH to 10.1.0.20 and then initiate a session to 10.1.0.23? does this work?

The output varies between the switches are they all the same type? Do they all have hostnames configured?

I will review the above but when you say you cant connect to 10.1.0.23 are you doing this remotely? Via VPN? What if you first SSH to 10.1.0.20 and then initiate a session to 10.1.0.23? does this work?

 

Yes I connect remotely via VPN which was never a problem until last weekend when we tried to replace the 3Com unit with the new 28 port Aruba as the Core. I have not tried the SSH option from one of the other switches to the 10.1.0.23 unit so will give that a shot.

 

The output varies between the switches are they all the same type? Do they all have hostnames configured?

 

3Com 4500 PWR 24 port PoE (Core switch) connected to

   HP 2530G 48 port PoE

   Aruba 2930F 48 Port PoE

   Aruba 2930F 48 Port PoE

   Aruba 2930F 28 port PoE (this is intedned to be the new core switch replacing the 3Com unit above)

HP V1910-24G - This is the switch labelled as MOFA in the lldp out put above. I don't know the Ip address of this... waiting for that info. I need to replace this unit with another HP 2530G switch which I have yet to configure.

To the best of my knowledge the Aruba's and HP switches have a single connection to the 3Com unit.

 

What if you first SSH to 10.1.0.20 and then initiate a session to 10.1.0.23? does this work?

 

I can ssh from 10.1.0.20 to 10.1.0.21 and 10.1.0.14 but ssh to the core switch 10.1.0.13 doesn't work there is a key exchange failure... but i think this is because of the way it has been setup... i don't want to spend too much time fiddling with this time because it is going to be replaced... once I fix the other issues.

 

So you cant SSH to .23 from the other switches? What about telnet? or PING? 

 

Can you please summarize what your actual issue is? Is it just that you cannot manage .23 via your remote session?

I had 2 concerns;

 

Firstly;

 

When we migrated all the connections off the old 3Com, we lost connectivity to our PBX for VoIP. This was eventually remedied by reconnecting the 3Com unit back to the network.

 

What I couldn't understand about this was that the new Aruba's were configured for both VLAN's on every port which was a change from the way the 3Com was setup which was a per port config, that resulted in us having to plug specific devices into specific ports on the 3Com unit. So I was surprised the migration to the new Aruba did not work. Upon migrating back to the 3Com core I was then not able to connect to the 10.1.0.23 unit. I double checked the connections and they "physically" appear to be fine.

 

Secondly, I wasn't too sure whether the configurations I had in place for the Aruba and HP switches was in fact correct....

 

My intention was to have the new 28 port Aruba operate as a layer 3 core switch and then have all the others route and transmit traffic (layer 2) through this switch... I had my reservations that this was in fact the correct config because that would mean the core switch would be doing all the work which is why I changed the config of all the switches to match that of the 28 port Aruba Core switch.

 

The last thing I was not sure about was correct was the interconnection between the core switch and all the other switch, googling did however confirm that the way I had them connected was in fact correct which is an uplink from each downstream switch to the Core switch. I will at some point add redundancy to the interlinks but I first want to get things working with the new Aruba Core switch in place.

 

I just don't know what I'm doing wrong in terms of the config assuming of course it is the config... which appears to be correct because the two 48 port Arubas and the 48 port HP switch are working fine and there have been no complains from users etc.

I've only just recently taken on networking at this level and my only previous experience was just basic knowledge of networks, subnets, routing etc.

Ok so i discovered that the new Aruba switch has gone back to a factory deault? I have no idea how this happened. Anyway I have uploaded the config and the switch is running ok.

 

The problem I now have is nothin on the VoIP network is contactable (servers) and none of the VoIP phones are getting an IUP address from the DHCP server.

 

All the switches are configured with ip addresses for both voice and data vlans, but I cannot ping anything on the voip vlan... which I could do with the old switch?

So I'm assuming there is some kind of routing issue on the new core switch... any ideas?

 

I've attached the config for the core switch. this is the same for all the switches except the model names, ip addresses etc for the vlans.

 

Thanks,

I can ping and connect to 10.1.1.x addresses between switches. That is to say i can login to any of the switch on their 10.1.0.x address and then ssh to another switch using their assigned 10.1.1.x address. Pinging also works fine between switches.

 

I have also run the following commands on all 48 port the switches;

vlan 1 untagged 1-48

vlan 2 tagged 1-48

end

wr m

then performed a reboot

and the following on the 24 port Aruba switch

vlan 1 untagged 1-28

vlan 2 tagged 1-28

end

wr m

then performed reboot.

 

I have rolled back to the old 3Com switch and everything is working again.

 

Is this a routing issue? I'm not an expert but I assume I need to have a config somehwere that tells the devices where to go for 10.1.1.x dhcp addresses which I though I had in there by adding the ip helper addresses.

 

Any ideas?

Tried the migration again today but still no luck. All the Aruba switches plus 2 HP's are working fine for vlan 1 which is the default vlan.

 

I cannot access vlan 2 (10.1.1.x) from vlan 1 (10.1.0.x) but I can ping all the switches EXCEPT for 10.1.1.5 from each other switch so the switches (apart from the one I mentioned) can communicate on 10.1.1.x. I can login via putty using 10.1.1.x so I'm not sure why the single 10.1.1.5 unit is not responding.... I tried changing the ip for vlan 2 from 10.1.1.5 to 10.1.1.7 but it tells me there is already an interface with the same ip/subnet or overlapping network... which isn't true. So I logged into the console and then used the Menu option to change the ip address but depsite no wanrings when making the change I still couldn't connect to the switch on its 10.1.1.5 address.

 

So I think the problem with migrating to the new Aruba core switch is that there may be no static routes from the gateway (Dell Sonicwall) back to the vlan 2 interface on the new aruba core switch so that it routes traffic for 10.1.1.x to the vlan ip address of the new core switch which will be 10.1.1.6 in this case.

 

So I think my solution would be to add a static route to the Dell Sonicwall telling it to route traffic for 10.1.1.x to 10.1.1.6 which is the VoIP vlan interface on the new Aruba core switch. At this point I'm not even sure if there is an existing rule which routes traffic to the current 3Com core switch on 10.1.1.1. Waiting for the client to get back to me.

 

Alternatively.....

Can I add a static route to each of the switches as follows;

 

ip route 10.1.1.0 255.255.255.0 10.1.1.6

 

10.1.1.6 being the new core switch ip address on vlan 2?

 

Can anyone verifiy that my reasoning is correct or advise what would be the best option?

 

Thanks,

My suggestion would be to create a trunk between devices.  That way you can simply tag the trunk.  Why are you tagging all of the access ports?

 

trunk 24 trk1 trunk (port 24 is designated as the trunk)

vlan 1 (Vlan 1 configuration)

untagged Trk1

 

vlan 2 (Vlan 2 configuration)
name "VLAN2"
tagged Trk1

Do the same thing on both sides, and make sure your gateway has the routes for VLAN 2

 

 

Yes that's what I was thinking... so you're saying that each port which is an uplink from the Core switch to an "access" switch should be changed to a trunk port and then tag and untag as required for each of the vlans?

I tried to change the port type to trunk from the command line but the commands I used did not work... switchport and port link-type just didn't work. So I will try straight from the WebGUI instead and see how that goes. I'm assuming that each of the ports have to be configured as a Trunk and then as Trk1?

 

I will try this when I get back to the office on Tuesday.

 

Why are you tagging all of the access ports?

Are you referring to the Core switch or the downstream switches?

I assumed that the downstream switches ports in access mode would be fine and on the core configure those with specific access as required. I'm just trying to get this working first and then I will hash out how best to configure indvidual ports? I am quite happy to take any advice you may have in this regard.

 

Thanks,

All the CLI commands you will need for this are here:

http://h20628.www2.hp.com/km-ext/kmcsdirect/emr_na-c04793912-4.pdf

 

Build trunks back to the Core, and make sure you have your tagging setting correct, all the way back to the core.  Test connectiving between each hop, on a per-vlan basis.

 

Let us know how things go?

Just to be clear, I would build one trunk between each hop, for connectivity back to the core.  Start with untagged traffic on VLAN 1, since that appears to be your native VLAN.  Once that is working, add VLAN 2 and tag the trunk for each hop.

 

If you require additional trunks, build them after you get network pathing working properly.

Ok so if I undestand things correctly....

 

I will need 4 trunk ports on the core switch (1 for each downstream switch).

Each trunk port on either side of the uplink (core and downstream) must be untagged for vlan 1 and tagged for vlan 2.

 

Next question: If a device is only configured for use on a single vlan should I then only configure the port it's plugged into for access to that vlan? The reason I had all the ports in access mode (default) was because they use IP Phones which are on vlan 2 and pc's connected to those ip phones using vlan 1, the DHCP server for both vlans is the same and sits on vlan 1. I thought that using tagged and untagged for the vlans means the ports can handle traffic from both vlans or is it because the gateway has a static route on in it which routes the traffic back to the core switch's vlan 2 interface. Are you saying that all the ports on the downstream switches should be configured in access mode but only allow for vlan 1? I'm new to all of this so just trying to get my head around things.

 

Aside from the obvious issues I'm having I wouldn't mind a lilttle insight into what the best way to do this would be. I know at the very least there will need to be a change at the firewall level. Currently they have the following objects on the Sonicwall which makes things easier to configure.

 

address-object ipv4 "Voice Gateway" host 10.1.0.13 zone LAN

address-object ipv4 Ministry-Voice-Only network 10.1.1.0 255.255.255.0 zone LAN

 

There is also a route on the firewall which states traffic from any source (for any service) destined for Ministry-Voice-Only (basically vlan 2) is routed to the entity "Voice Gateway" above which is the current 3Com core switch through port X on the Sonicwall which is the LAN interface.

 

So my assumption would be apart from making the required trunk changes and any other recommendations from my fellow AirHeads I would need to create a new address object for the new Aruba core switch and then update the route with that host. If for whatever reason it doesn't work I can just change it back to the 10.1.0.13 object.

 

Thanks,

Next question: If a device is only configured for use on a single vlan should I then only configure the port it's plugged into for access to that vlan? The reason I had all the ports in access mode (default) was because they use IP Phones which are on vlan 2 and pc's connected to those ip phones using vlan 1, the DHCP server for both vlans is the same and sits on vlan 1. I thought that using tagged and untagged for the vlans means the ports can handle traffic from both vlans or is it because the gateway has a static route on in it which routes the traffic back to the core switch's vlan 2 interface. Are you saying that all the ports on the downstream switches should be configured in access mode but only allow for vlan 1? I'm new to all of this so just trying to get my head around things.

 

This totally depends on how you want this to work. If you have a VoIP VLAN, then you want your phones to be in that VLAN. If you connect a PC to a phone (share a cable & switchport) then you need to have the data VLAN as 'Untagged' and the VoIP VLAN as 'Tagged'. This is becuase, generally, the phones have the ability to tag thier packets whereas the PC's dont. Next you need to work out how the phones are going to know or learn they should be in the VoIP VLAN. There are multiple ways for this; static config on the phone, learn via LLDP/CDP (additional switch config required & phone support) or via DHCP vendor specific option. Do you know how your phones discover the voice VLAN at present?

 

 

The phones are configured manually to use vlan 2 so that isn't an issue. The client only has about 80 - 90 phones so it's not a big deal because when they get new phones they come preocnifgured already to use vlan 2. So given that, I'm assuming that leaving the ports in access mode with vlan 1 untagged and vlan 2 tagged this would be fine?

 

Routing is by default disabled at a Aruba switch. To Enable routing use the command “ip routing” at the core/l3 switch. Only at de core and not at your other switching what are kust L2 switches. The L2 switches only needs a IP in the management network.

At the firewall ADD a static route the the core switch which will point to the connected interface IP of the switch. So the next hop is the ip of the core switch in the same network as the firewall.

It’s also advisable not to use vlan 1.

Thanks for all the great advice... learnt a great deal with this exercise...

 

So to recap this is what I understand as to be the recommendations made.

 

1) Configure trunk ports between the core switch and each downstream switch.

2) Tag vlan 2 and untag vlan 1 traffic on these trunk connections.

3) Remove the ip route to the default gateway from all but the core switch.

4) on the downstream switches set the ip route 0.0.0.0 to x.x.x.x. where x.x.x.x is the core switch?

5) Add a static route to the gateway/firewall which routes traffic for vlan 2 to the core switch? Do i route this to the vlan 2 ip address of the core switch or the vlan 1 address and it will send the traffic to clan 2 on its own?

 

Does that sound about right? Have I missed anything?

 

Thanks,

Another query on this....

I understand that an access port is generally used when you only have 1 vlan which is untagged... that is the port will only carry untagged vlan 1 traffic and drop traffic for any other vlans? Is that correct?

 

If I have VoIP phones which are capable of tagging traffic for vlan 2 which is for the VoIP system does that mean any port connected to a VoIP phone should be a trunk port? Currently all the ports are in access mode though I have tagged vlan 2 and untagged vlan 1 traffic and the phones are working fine?

So what is the recommended way to connect the VoIP phones to the network, the phones provide a port for workstations to plug into and they only use vlan 1 and the workstations work fine too.

 

Just trying to figure out what the best practice would be/is?