Tech Note: Command Line for Alternate PAC file for Chrome

27th Jun 2012 By Greg Ferro Filed Under: Blog, Blue Coat, Tech Notes

Sometimes you need to use many different Proxy Auto Configuration files with a web browser, usually when testing or trying out new installation of the proxy servers. Most browsers have command line options that let you specify different PAC files to use which can then be configured so that you have multiple startup options.

/path/to/Chrome --proxy-pac-url=file:///path/to/config.pac

The actual command line for starting Chrome on Mac OSX is

/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome

add your own extensions for the PAC file as you need to.

PacketShaper and Flow Directions

15th May 2011 By Greg Ferro Filed Under: Blog, Blue Coat, Design, Operation

I stumbled across an old diagram I made a long time ago about the direction of flows on a BlueCoat PacketShaper. Since I’ve been looking for it for about three years, I’ve diagrammed it quickly so that it is here for future reference when I’m working PacketWise in the future. PacketShaper PacketWise is one of my very favourite tools for managing traffic flows, and much preferable to PHB QoS aka DiffServ for many types of use cases.

TCP Flow and Sessions

An TCP flow has four possible directional attribute related to the use of “inside and outside” networks, and whether the flow was initiated from the client to server which sets the “direction” of the flow relative to the Packeteer. The flow is determined by who initiated the three-way handshake. For purposes here, the Client always initiates the TCP connection, and the Server terminates the connection.

TCP Session and Direction

Most people understand the three-way handshake, but not many consider the direction of the session. That is, TCP establishes two connections between each client and server – one in each direction.
The connection from the client to the server is outbound, but is inbound on the server. And vice versa, the server outbound session is inbound on the client. That’s not very useful for being able to define the direction of flows. Because it’s a bit confusing, so I use the term client-to-server session and the server-to-client session.

Why is direction important ?

Direction of flows is important if you want to configure asymmetric rules. That is, not all protocols require symmetric bandwidth. For example, HTTP traffic is usually a 10:1 ratio for reply to request. That is, a request for this webpage is about 10KB, but the reply with the data, images and JavaScript is more than 100KB.

For a FTP upload server, you might have the reverse condition where the inbound traffic is far more than the outbound.

To make the most of your Internet connection for this case, you could configure the inbound bandwidth on your Internet connection to be 80% FTP, 20% HTTP and the outbound bandwidth to be 20% FTP and 80% HTTP. This gives a far better utilisation, especially in regards to better TCP Windowing and overall TCP goodput.

Inside and Outside

For the purposes of a direction, the PacketShaper is usually connected with the Outside interface to the router, and the Inside interface to the internal switch. This establishes the source / destination directions.

Thus the traffic direction for Outbound is traffic initiated from Inside to Outside, and Inbound from Outside to Inside.

It’s vital to understand this, since the PacketShaper separates flows into Inbound and Outbound in the traffic tree as the primary separation. However, to configure asymmetric flows, we still need to differentiate between client to server, and server to client connections.

Outbound Destination Flows

Extending the logic so far, the PacketShaper will classify outbound flows for clients and servers like this:

Inbound destination Flows

The PacketShaper regards Inbound/Outside and Inbound/Inside in this form relative to the client and server.

The Full Map

This is the diagram I refer to when configuring my PacketShaper and trying to determine the direction of the flows for the purposes of Rate Control. It shows the four possible directions and their relationship to the PacketShaper device.

Hope this helps you as well.

Help ?

This post would be a lot better if I had some screenshots of the PacketShaper configuration page but, alas, I don’t have any test units to create some dummy web pages to show you how it appears on the page. I wonder if anyone can send some screenshots to [email protected] and I’ll see if I can use them to extend this post.

Cisco IOS load balancing for Blue Coat SGOS

12th Aug 2009 By Greg Ferro Filed Under: Blue Coat, CCIE, Cisco, Design, Operation

A regular question for Blue Coat is how to achieve high availability. One of the answers is use a load balancer, and most networks already have a load balancer but don’t know about it.

The IOS Server Load Balancing (SLB) is good for most cases requiring load balancing and for load balancing two ProxySG makes an excellent solution for small and medium networks.

[Read more…]

Blue Coat to Acquire Packeteer-excellent-outcome

21st Apr 2008 By Greg Ferro Filed Under: Blue Coat, Opinion

Fantastic news! As a long time user of Blue Coat and Packeteer, I am pretty excited about this. The Packeteer traffic management technologies is a long way ahead of the Cisco queueing strategy, and the Blue Coat product set has plenty of features that hold Cisco at bay in the WAN Acceleration (previously known as Traffic Management….sigh…queue the whale song)

Let hope this completes quickly and cleanly.

Blue Coat to Acquire Packeteer to Offer Comprehensive Solution for WAN Optimization | Blue Coat Systems, Inc.: “”

Om Malik has a few comments as well:

(Via http://gigaom.com/2008/04/21/bluecoat-systems-buys-packeteer/.)

Thank goodness Nortel didn’t get an oar in.

http://gigaom.com/2008/04/20/packeteer-bid-bluecoat-nortel/.

Blue Coat ProxySG VIP and Cisco switches need Multicast enabled

30th Mar 2008 By Greg Ferro Filed Under: Blue Coat, Cisco

About VIP and SGOS

If you decide to use VIP for high availability on Blue Coat ProxySG, then you need to understand how it works. It is very similar to VRRP. That is, both units are configured to share the same IP address, and a priority is configured on each unit to define which ProxySG will be the master. They use multicast to broadcast their status.

You want to have two Blue Coat ProxySG, so you connect them to two switches so that redundancy is improved. Like so:

Both ProxySG will then send multicast packets to advise the other ProxySG that it is up and the priority is contained in the multicast packet, along with the IP address of the VIP and so on. If you are going to have multiple VIPs in a single Layer 2 LAN segment, make sure you use different multicast addresses for each VIP cluster. Note also you can have some interesting design opportunities using three or four VIP per ProxySG for a active/active/backup design (maybe an article for another day, leave a comment if you are interested.).

Because you are using IP Multicast (2) your switch must be able to handle IP Multicast. There are two ways for a switch to handle IP Multicast, one is broadcast it to every port like a hub would, or to use Internet Group Multicast Protocol (IGMP). When broadcasting to every port, every host on that broadcast segment has to listen to the packets, receive into the IP buffer and read them before discarding the information.

This causes significant CPU cycles to be lost to unwanted traffic flows. IGMP is protocol that is enabled on the switch that monitors multicast packet for certain information and decides whether to enable or disable the multicast flows on switch ports. To join a Multicast flow the host or endpoint will issue an IGMP join message for a given IP address, the switch will record this and any responses from other hosts and make sure that those ports will not be closed for that Multicast IP address. After some time, other ports that do not request to be part of the Multicast address will have the Multicast traffic for that address blocked. (3)

By default, Cisco switches have IGMP enabled (4) and they will build an IGMP snooping table for all ports on the switch. Consider the following diagram:

Step 1 – both ProxySG issue a IGMP membership to their switches
Step 2 – switches record membership of the multicast group

What the Cisco switches do not do is notify their neighbour that they should forward the multicast traffic between SW1 and SW2. Which is exactly NOT what you would expect. The IGMP packets have been terminated by the switch and not forwarded. As a result, multicast traffic is not forwarded between the switches.

When using Blue Coat ProxySG you will know you have this problem because both VIPs will show as master.

Cisco switches need a Multicast router (mrouter)

The best solution to this problem is to setup a IOS device somewhere as Multicast router. When the switch gets an IGMP report it will then relay the notification to the mrouter. The mrouter will then send IGMP messages that notify all switches about their Multicast group membership and everything will be well.

Sample IOS configuration

interface Vlan1
ip address 198.18.1.10 255.255.255.0
ip pim sparse-dense-mode
end

Switch1#show ip igmp snooping mrouter
vlan ports
—–+—————————————-
1 Router

Use MPLS VRF to create a Multicast only interface

Use an MPLS VRF to create a completely isolated IP interface and enable IP on that interface.

!
!enable multicast routing
!
ip multicast-routing
!
!this creates a standalone vrf
!
ip vrf proxy
rd 100:104
!
!now create an interface that is in the VLAN that the ProxySG are using.
!
interface Vlan3502
ip add 198.18.1.1 255.255.255.0
ip vrf forwarding proxy
ip pim sparse-dense-mode
!

Enable IGMP Querier Feature on a Layer 2 Catalyst Switch

From the Cisco web site

“IGMP querier is a relatively new feature on Layer 2 switches. When a network/VLAN does not have a router that can take on the multicast router role and provide the mrouter discovery on the switches, you can turn on the IGMP querier feature. The feature allows the Layer 2 switch to proxy for a multicast router and send out periodic IGMP queries in that network. This action causes the switch to consider itself an mrouter port. The remaining switches in the network simply define their respective mrouter ports as the interface on which they received this IGMP query.”

Switch2(config)#ip igmp snooping querier

Switch2#show ip igmp snooping querier
Vlan IP Address IGMP Version Port
————————————————————-
1 1.1.1.2 v2 Switch

I don’t want to use Multicast.

If you have some passionate gripe about not enabling Multicast on a single interface, you can create static ARP entries for the Multicast MAC address on every switch that is in the data patch. If you have multiple data paths, remember to configure that on every switch in all possible data paths.(5)(6).

I would only recommend this in small networks.

Switch1(config)#mac-address-table static 0100.5e6f.efef vlan 1 interface gigabitethernet 2/46 gigabitethernet 2/48

!— Note: This command should be on one line.

Switch1#show mac-address-table multicast vlan 1

vlan mac address type learn qos ports
—–+—————+——–+—–+—+——————————–
1 0100.5e18.010a static Yes – Gi2/46,Gi2/48

Switch2(config)#mac-address-table static 0100.5e18.010a vlan 1 interface
gigabit 1/47

!— Note: This command should be on one line.

Switch2#show mac-address-table multicast vlan 1
Vlan Mac Address Type Ports
—- ———– —- —–
1 0100.5e18.010a USER Gig1/47

Disable IGMP Snooping on All the Switches

If you disable IGMP snooping, all switches treat multicast traffic as a broadcast traffic. This floods the traffic to all the ports in that VLAN, regardless of whether the ports have interested receivers for that multicast stream.

Switch1(config)#no ip igmp snooping

Switch2(config)#no ip igmp snooping

References

(1)Cisco Web site – Multicast Does Not Work in the Same VLAN in Catalyst Switches. Excellent reference and this article is largely drawn from information here.

(2) Note IP Multicast and Ethernet Multicast are very different things. Note everyone realises this.

(3) Not all IGMP implementations are equal. Some vendors do this badly and some unmanaged switches don’t support IGMP at all. It is much cheaper to make a switch that does not support IGMP.

(4) This is not true of cheap switches – see (3), they disable IGMP to have more CPU cycles for day to day. Most people will never know the difference.

(5) In a big corporate LAN where your ProxySG are in different buildings, this could mean configuring static arp entries on dozens of switches.

(6) You must work out the MAC address from the Multicast address. Here is a link, there are others

Tech Note: Command Line for Alternate PAC file for Chrome

PacketShaper and Flow Directions

TCP Flow and Sessions

TCP Session and Direction

Why is direction important ?