will this work?

[mechsupply]

I was asked to check this out for a friend that is having some problems.
Can I get somebody to check out this topology and tell me if I am right or wrong?

http://i780.photobucket.com/albums/yy86/mechsupply/Untitled.png

The problem they are having is the two PS7500 units highlighted the expansion lems cross conneted read as 1/1down. From my understanding you cannot have the two units wired as such and I suggested this as I found on bluecoats guides.

http://i780.photobucket.com/albums/yy86/mechsupply/topology.png

let me know if I am off base here

[StuartM]

If they are using Direct Standby this is fine. It looks like they have a single-LEM direct standby setup. A second LEM would add additional redundancy but is not mandatory. In direct standby, the outer port on the LEMs are connected directly to each other via crossover cable. It has to be outside to outside and there can be no devices in between. So is the problem that the link lights are not coming up at all? If this is the case, after verifying that they are using a crossover cable, I would look at the NIC settings. Auto-neg on both may be best.

Additional, information regarding Direct Standby can be found here:

https://bto.bluecoat.com/packetguide/8.5/nav/tasks/tasks-standby.htm

[mechsupply]

Each does have two lems but they are just using the two (far right hand) They have tried setting it to auto and manual and that will work for a little while.
mpnqs7003 Unit 1
unitInside nic speed: 100BaseT full-duplex (link is down)
Outside nic speed: 100BaseT full-duplex (link is down)
Left_inside nic speed: auto-negotiate (1000BaseT full-duplex) <connected
Left_outside nic speed: auto-negotiate (link is down)
Management nic speed: auto-negotiate (link is down)

mpnqs7004 Unit 2
Inside nic speed: 100BaseT full-duplex <NIC is connected and up
Outside nic speed: 100BaseT full-duplex (link is down0
Left_inside nic speed: auto-negotiate (link is down) <Not connected
Left_outside nic speed: auto-negotiate (1000BaseT full-duplex)<Connected
Management nic speed: auto-negotiate (link is down)<not connected
Tried swapping nics and with the same errors and swapped machines with two units form incoming side with all the same result.

[mechsupply]

would the presence of the second Lem (not being used) in each unit cause a possible issue??

[mechsupply]

I did get a little more info from them on this morning.
The boxes are running different PacketWise revisions 8.3 and 8.5 different plugins and passwords all of which are a no No's in direct standby so this may be part of the problem. I am also having them turn off link state mirroring to see if we can remove a switch fault from the equation.
any other ideas in case this doesnt solve it?

[StuartM]

OK, I think it is making more sense now as to why it's failing. See the following page for a list of direct standby requirements:

https://bto.bluecoat.com/packetguide/8.5/nav/overviews/high-availability-overview.htm

As far as I can tell you need to do the following:

1) Use the right-most LEM for the direct connection, not the left. Also, it must be right outside port to right outside port. From the output it looks like they're connect left inside to left outside.

2) Check all interface cards, but especially the right-most, to make sure the bypass jumpers are out. You can do this without opening the box. First enable debug commands:

sys set showdebug 1

Then run the command:

sys dio stat

Some sample output:

PacketShaper# sys dio stat
Passive connector (Motherboard) disable jumpers are in (enabled).
Passive connector (Left) disable jumpers are out (disabled).
Passive connector is opened.

I don't have my PacketShaper configured for direct standby but it shows jumpers are out on my Left card because it is fiber. disable jumpers should be "out" on all cards. If it does not meet this requirement, the PacketShaper will not alow you to enable direct standby. The error will be:

This PacketShaper is not configured to support Standby mode.

3) The PacketShapers must be configured with the same touch password. This is mandatory. They should also be on the same software version and have the same plugins. This will not make it fail but your class trees will be out of sync once it starts discovering traffic.

4) Link state mirroring may make troubleshooting confusing if you have not enabled Direct Standby. With direct standby off, link state mirroring will prevent a port from coming up if the other port in the pair is disconnected. However, once direct standby is enabled, link state mirroring does not apply to the right LEM. To simplify things, disable link state mirroring, make the right outside to right outside connection, enable direct standby, then enable link state mirroring again. Alternatively, you can just disregard the fact that the link is not coming up on this LEM and just enable direct standby. It should come up after that.

[mechsupply]

Do the 3500/7500 lems have jumpers? Or is it on the motehrboard?

[StuartM]

Yes, the LEMs have jumpers if they are copper NICs. Fiber cards do not have jumpers since they do not have built in bypass relays. The command "sys dio stat" will tell you whether they are in or out. This link shows you where they are on the motherboard:

https://bto.bluecoat.com/packetguide/8.5/nav/tasks/standby/disable-relays-3500-7500.htm

On both the motherboard and the LEMS, it will be a row of jumpers found between the inside and outside NICs.

[mechsupply]

Ok
Update on this . I found out they did not have the unit set for direct standby (pins in standby disabled) I got them to send the units in to my shop as they insisted that this was not the problem. I benched the units and replicated the topology . (with pulling jumpers and enabling standby config) Once up everthing worked as it should over the weekend. So I thought that was that.
I sent he units back to the sight yesterday and they tried them today and this is the response I got back
I got these back in the racks today.

Packet shaper 1—MPNQS7003

Onboard Inside LEM – Connecting to Internal Switch 1 ß MPNSW7003 port 1
Onboard Outside LEM – Connecting to External Switch 1 ß acnmmsw002 2/36
Expansion Slot Outside LEM – Connecting to Packet shaper 2 expansion slot Outside LEM ß Connecting using cross over cable



Packet shaper 2—MPNQS7004

Onboard Inside LEM – Connecting to Internal Switch 2 ßMPNSW7004 Port 1
Onboard Outside LEM – Connecting to External Switch 2 ß acnmmsw001 2/36
Expansion Slot Outside LEM – Connecting to Packet shaper 1 expansion slot Outside LEM ß Connected using cross over cable

Also the requirement is Internal Switch 1 & 2 and External Switch 1 & 2 should not be stacked together. Neither of the inside or outside pairs of switches are stacked together.

All of the switchports on the SUS side are set to auto speed and auto duplex. As soon as I connect the packet shapers, both ports on our switches went into err-disable mode. The inside interfaces went down too, but I don’t have access to those switches so I cannot tell what state they are in

The only way I can replicate the problem they are having is by stacking the switchs.

I am thginking that something else in their network has to be misconfigured but I cantt tell what it would be.ANY IDEAS??

[StuartM]

Does their topology work without the PacketShapers in place? That is, with internal SW1 directly connected to external SW1 and internal SW2 connected to external SW2. If you perform the following steps in order, at which point does it break?

1) Power on both PacketShapers.

2) Connect PacketShaper 1 inside and outside.

3) Connect PacketShaper 2 inside and outside.

4) Enable direct standby.

Some added info regarding direct standby... A PacketShaper only has a single management IP address. It may respond to an ARP request for this IP with multiple MAC addresses. That is, if it receives an ARP request on the inside port, it will respond with that PacketShaper port's MAC address. If the ARP request is received on the outside port, it will respond with that port's MAC. In direct standby mode, you can force the PacketShaper to use a dedicated management port by simply connecting the inside port on the Expansion slot LEM to the network. If this is port is connected, it will only respond to management requests on this interface. Also, linkstate mirroring is enabled automatically. I want to stress that this only applies when direct standby is enabled. If it is off, the PacketShaper continues to respond to management requests on all ports.

[mechsupply]

The network was functioning with the shapers out.
Same error with or with out direct standby enabled.
Link state mirroring is off (was turned off in case there was a problem with the switch)

[mechsupply]

management is being done on inside port of native interface. (no conection inside of lem)

[mechsupply]

we tried only running just one first unit and connected the cables and the link lights came on, then they went out. The switch ports showed err-disable. The second unit is not even connected to the network.

[StuartM]

Try the following:

1) Connect to the console port with a serial cable.

2) Run the command "set manage on". This enables dedicated management access from the MGMT port, which you can leave disconnected. It will lock down the main interfaces as far as management goes, but they will still classify traffic.

3) Connect the PacketShaper to the network.

4) If all goes well up to this point, try connecting the MGMT port to the internal network.

If you use the MGMT port for management, this prevents the switches from seeing the PacketShaper IP advertising two MACS sandwiched between a pair of switches. It will be seen as a single IP with single MAC on the inside of the internal switches.