Continue reading »]]> So Juniper Networks (JNPR) have launched a new idea in switching, expanding the swicthing fabric across muliple chassis in thier QFabric switch platform.

In thier launch video (it’s 76 minutes long, 45 minutes of launch video, and 30 minutes of Q&A), they show that they have been able to achieve this with several ideas that come from the Autonomic Networking cookbook.

• Push the intelligence at the edge
• Simply the core transport layer
• Simplify the management and complexity
• Removal of the impact of single points of failure from the platform

It’s nice to know that there aren’t to many new ideas in the world, and that Ipanema Technologies 11 years ago understood most of them. More later as Juniper reveals the QFabric Interconnect and QFabric Director.

Continue reading »]]> Juniper (JNPR) has announced in the last couple of days End-of Life for the WX100 devices. This effectively kills off the WX stack architecture as a side-effect.

The WX-100 was typically never found in standalone deployments, but formed the hub of the WX stack architecture, now capacity improvements will need to be engineered for individual devices using configuration and design methods, rather than a pool of devices, maybe using individual WCCP pools.

Continue reading »]]> Juniper (JNPR) has announced the End-of-life for the WXC500 device.
End of availability is 31 May 2010, with final end of support at 31 May 2015.

This is the last of the old Peribit style devices to be removed from the Juniper portfolio, leaving just the new WXC platforms available, along with the WX100 device used to drive the WXC Stack architecture.

Continue reading »]]> Juniper (JNPR) has announced the end-of-life for the WX platform and the WXC-250 devices. The end of availablity is 5 May 2009, with the end of support at 31 May 2014.

This is the overdue killing off of the WX platform, leaving only the WX100 as the stack controller. The low-end WXC250 is replaced by the Juniper WXC1800 and WXC2600 devices recently announced. (See “New Juniper WXC appliances“).

Continue reading »]]> On Monday Juniper launched some new bits of kit in the WXC line, the WXC-1800, WXC-2600, and WXC-3400 devices.

The new appliances are partial replacements and extensions over the existing WXC platforms, and they’ve taken the additional capabilities of the platforms to reposition devices a little more cleverly than the WXC-250, 500 and 590..

The range consists of the following..

WXC-1800 – This seems to be a replacement for the WXC-250, but in a form-factor more closely resembling the WX-15 device. It has a larger hard disk, doubled in size to 80GB, and has a starting point of a 512Kb/s license. It still retains a 10 tunnel limit.
WXC-2600 – This is a middle device, fitting between the old WXC-250 and WXC-500 units. It supports upto 8Mb/s, using a larger 250GB hard disk, and with the potential for 20 tunnels. This is the same physical size as the old WXC-250 unit, but is nearly 2Kg lighter. The key take-away is the power-draw, doubled to 300W max, in part due to the larger hard disk, but a larger portion is almost certainly going to be a more powerful processor, and I’d guess more memory (especially since memory has got substantially cheaper over the intervening years)
WXC-3400 – This is the top end device, designed for the data centre.. It features 1TB of disk, but is still a 2U unit. This draws 400W max, up from the 300W of the WXC-590. Licenses start at 10Mb/s, and rise to 45Mb/s.

All these units have a pair of 10/100/1000 Copper Ethernet ports, except for the WXC-1800 device, which is limited to 10/100 Copper Ethernet ports, for connection to the network in in-line or off-path modes.

Continue reading »]]> So investigating some issues for the inks company today, I come across a problem that we’ve seen before with Junipers..

A site has problems transferring data across the network between two Junipers, since we’ve been through the mill already for this application, there is a special exclusion application definition for this. So we try the usual trick, which is disable the NSC (disk-based) compression and TCP acceleration by sticking the failing server in the exclusion application. Re-run the transfer, and the problem still exists..

Since we’ve done this, we’ve added several other Juniper sites to the network, along with several hundred users. This means that the pair of servers involved are facing some increased loads from the other functions carried by the server. (The application comes in three parts, one that gathers the data, one that processes it, and the third that supplies that information out to the rest of the organisation. The issues that we have seen so far have all been related to the gathering of the information, since that is the process that generates and logs errors, and is also noticed in missing information if it fails).

The issue is not in the problem of the gathering of the data, but in the probable undersizing of the system(s) that runs the entire application. The problem appears that the system has a finite amount of network buffer space to send or receive the data via the network. If the acceleration for the entire system (both the gathering and publishing sides) is enabled, then we have an issue in which the transfers hit several points of TCP zero window on the gathering side (which was being measured today). This means that the server is running out of space in the system (it normally signifies a bottleneck within the system that prevents the received data being processed effectively). This is not surprising, since the process contacts remote databases, and drags information from them into a consolidated central store (data warehouse). The zero window can also mean that the system at the operating system level is unable to accept more data since the buffer space is exhausted.

By adding the gathering connections into an application definition that precludes the TCP application function, the volume of data being received is throttled (since the TCP window now comes into play for the particular server we’ve got an issue with, since it is South Africa, and the data warehouse is in Arizona, USA). This has in the past restored function for the gathering function, but in the intervening time we’ve added several more users that are using Junipers to connect to the publishing side of the application, and this has increased the load on the total system buffers, since more are now occupied with data leaving the system on it’s way towards it’s subscribers. In the end, disabling TCP acceleration for both sides (gathering and publishing) of the application reduced the loading on the server, and enabled the system to complete both tasks without errors.

I’m fairly convinced that an analysis of this server will show that it is highly overloaded, and that a good dose of memory and some careful operating system tuning of the network stack will enable the TCP acceleration to be enabled again. (Part of this comes from a comment that the processing of the data can take “quite a long time, nearly an hour a site”, when it’s only 10Mb of data that are transferred across the network itself.

So if you’ve got issues with TCP acceleration, and it affects a single server, then it might be an idea to ensure that it’s operating correctly. Check the application loading levels, the level of swap file in use, and the amount of memory that is being reserved for network buffers. It’s not true that you can simply enable TCP acceleration without an impact in the network. You are automatically making each connection work harder, and this will take more resources in the system to support, especially if the system load remains constant.

So there is impact on servers under TCP acceleration, and it ain’t necessarily all good. Make sure your system can cope with the extra network buffer utilisation needed.

Continue reading »]]> It transpires that the issue with IGMP snooping needing to be disabled on certain switches is due to the partial implementation of the multicast IP support within the Juniper WXOS software.

For switches that have IGMP snooping feature, this normally enabled on these switches, and most support IGMP v2. This requires both the multicast end device to advise that the multicast group has been joined, but also that the multicast router to query the end device periodically to determine if the device is still actively part of that group.

IGMP snooping on the switch monitors these messages and enables or disables the forwarding of multicast packets to the particular port that responds, and closes off the port if no membership report information is returned to the router. Because the Juniper does not support IGMP v2, these switches will withdraw the multicast forwarding for the Juniper WXC port as it’s not part of the multicast group that the switch recognises via IGMPv2.

Disabling the IGMP snooping prevents the shutdown of the multicast traffic to non-member ports, and instead floods the multicast traffic to all ports, similar to broadcast traffic processing. As this traffic is now forwarded to the Juniper (and incidentally to all other devices connected to the switch), the WCCP relationship between the Juniper and the routers is maintained. Correct operation of this feature can be seen using the show packet-interception command. This will show the HereIAm and ISeeYou WCCP messages (HereIAm is issued by the Juniper, ISeeYou comes from the routers). Both should be increasing, if the IGMP issue occurs, what is shown is the HereIAm messages continue to be emitted, but the returned ISeeYou messages are prevented from reaching the Juniper via the switch, and this counter stops.

Time for a feature request, methinks..

Continue reading »]]> So the consultant from the Inks company phoned again, and needs a little help. Seems that the HP JetDirect printing to some of their sites has broken, since the transition to the new network.
A bit of a look, and some disabling and re-enabling some functions later, and we get back to everything working for a site connected via an IPSec VPN link, with no overall changes.. but now it works.

For the other site, we have an issue that might have been a TCP MSS size problem (connections starts, but fails to transfer data). Fudged the Juniper WX devices with a lower MSS size for accelerated traffic but no dice. It did appear as if the hard disk was busy, so took the traffic out of NSC (the disk based compression engine), again no dice. Disabled TCP acceleration, and everything’s hunky-dory..

The only part of the network which had Junipers at both ends was the other providers connections between the data centers. I’m still certain that they fudge the MTU on their network, even though the changes to MSS should have worked around this. Still another case to open with JTAC. At least we have full traces and diag files for this one.

Continue reading »]]> The new Juniper software for the WAN acceleration products (WX and WXC series devices) provides for the use of out-of-path deployments. Whilst this can help in simplifying the deployment scenarios for the devices into more complex networks, this needs to be considered carefully.

For a normal small site, the best deployment method is the traditional in-path deployment, with the device inserted between the LAN and the router. This means that you have a single thread connecting the LAN to rest of the network, which is great if you need to support multiple routers, you’ll need an external switch on the WAN side to make this happen.

By using WCCP, you can configure a single device to support a pair of routers, and by potentially reducing the traffic through the device, (since WCCP can only redirect the traffic that gets compressed or accelerated), you might be able to squeeze a little more horsepower of the device..

Some lab time is needed for this, methinks..