Moving from Explicit Proxy to Transparent Proxy – part 1

Proxy can  be implemented in either a explicit or transparent mode. The deployment of proxy (network logical location) can be either in-line (bridge) or out-line. Since we are planning to more from the explicit mode to transparent mode, various changes are required to be done, on both network and security levels. Lets review how the current network setup is.

1. The default route is pointing toward the firewall.
2. firewall is part of Server Farm Vlan (wrong design).
3. Proxy are configured to be inline. one leg in server farm, the other leg directly to the internet. (wrong design).
4. All internal IPs are converted into one IP (many to one).
5. Since it is explicit, the returning traffic will always come back to the proxy

In the second part, I would go into the details of our target design, and how we would want our traffic to go.

How to configure ProxySG to cache youtube video?

Many medium to big organizations use ProxySG to filter and control the traffic leaving the enterprise network. One of the big strengths of Bluecoat ProxySG is the cache. It is one of the best cache devices out there in the market.

As we all know, youtube can be considered one of the main web applications that eat up the bandwidth. The content is very dynamic, and the url’s are ever changing. one of the main issues with youtube videos that they are served from various mirroring websites. Thus, proxySG can’t cache the videos by default since the URL are different for the same data. I have came across a policy that can be added to ProxySG. This will enable youtube caching!

<Proxy “YouTube specific caching rewrite”> condition=youtube_related_request
condition=youtube_seek_video_requests ; leave seek requests alone, not caching
condition=youtube_video_request_style1 url.query.regex=”itag=34″ action.rename_youtubeSD(yes)
condition=youtube_video_request_style2 url.query.regex=”itag=34″ action.rename_youtube_style2SD(yes)
condition=youtube_video_request_style1 action.rename_youtube(yes)
condition=youtube_video_request_style2 action.rename_youtube_style2(yes)
condition=youtube_host_patterns condition=youtube_video_requests action.rename_youtube_url_hostname(yes)
<Cache “video content”>

; YOUTUBE & GOOGLEVIDEO – 10 days
[rule]
condition=youtube_seek_video_requests cache(no)
condition=youtube_video_requests ttl(864000) force_cache(all)

; YOUTUBE DEFINITIONS
;
define condition youtube_related_request
request.header.Referer.exists=yes condition=youtube_referer_present
condition=youtube_host_patterns
end

define condition youtube_host_patterns
url.host.substring=”youtube”
url.host.substring=”googlevideo”
url.host.is_numeric=yes url.address=youtube_subnets
end

define subnet youtube_subnets
;; these can be fairly broadly drawn, since appearance in here
;; alone does not itself force youtubeization; the request also
;; has to be relatively youtube specific.
;; IE this is an optimization, not a pure correctness filter
; observed in eval logs Mar2010

74.125.0.0/16    ; GOOGLE NET-74-125-0-0-1
173.194.0.0/16   ; GOOGLE NET-173-194-0-0-1
;204.246.234.23/24 ; used by cache but assigned to frontiernet.net
;youtube_ARIN_IPs
;IPv4 CIDR:
208.65.152.0/22  ; YOUTUBE
64.15.112.0/20   ; YOUTUBE2
208.117.224.0/19 ; YOUTUBE3
72.51.34.221/32
72.51.34.222/31
72.51.34.224/29
72.51.34.232/30
72.51.34.236/32
72.51.35.205/32
72.51.35.206/31
72.51.35.208/30
72.51.35.212/32
; 75.35.233.64/29   ; now sbcglobal
; 75.31.180.240/29  ; now sbcglobal
76.210.160.216/29
76.208.211.160/29
; 75.48.116.72/29   ; now sbcglobal
75.55.218.8/29
;IPv6 CIDR:
;2620:0000:0040:0000:0000:0000:0000:0000/48
;
;youtube_RIPE_IPs
;IPv4 CIDR:
194.221.68.0/24
195.27.182.0/24
195.59.171.0/24
213.146.171.0/24
82.129.37.0/24     ; YOUTUBE-EUROPE
89.207.225.0/24
209.85.128.0/17    ; Seen at Mobily
end

define condition youtube_referer_present
request.header.Referer.url.substring=”ytimg”
request.header.Referer.url.substring=”youtube”
request.header.Referer.url.substring=”video.google.com”
end

define condition youtube_video_request_style1
url.path.exact=”/get_video” url.query.regex=”video_id=”
end

define condition youtube_video_request_style2
url.path.exact=”/videoplayback” url.query.regex=”id=”
end

define condition youtube_video_requests
condition=youtube_video_request_style1
condition=youtube_video_request_style2
end

define condition youtube_seek_video_requests
url.path.exact=/videoplayback url.query.regex=”begin=[1-9]”
url.path.exact=/get_video url.query.regex=”begin=[1-9]”
end

define action rename_youtube
;–NOTE the following is one line (approximately 120 characters long)
rewrite(url, “(.+)video_id=([^&]+)(\&.*|$)”, “http://youtube.proxysg-cache/get_video/$(2)”, cache)
end

define action rename_youtube_style2
;–NOTE the following is one line (approximately 120 characters long)
rewrite(url, “(.+)id=([^&]+)(\&.*|$)”, “http://youtube.proxysg-cache/get_video_style2/$(2)”, cache)
end

define action rename_youtubeSD
;–NOTE the following is one line (approximately 120 characters long)
rewrite(url, “(.+)video_id=([^&]+)(\&.*|$)”, “http://youtube.proxysg-cache/get_video/$(2)_SD”, cache)
end

define action rename_youtube_style2SD
;–NOTE the following is one line (approximately 120 characters long)
rewrite(url, “(.+)id=([^&]+)(\&.*|$)”, “http://youtube.proxysg-cache/get_video_style2/$(2)_SD”, cache)
end

define action rename_youtube_url_hostname
rewrite(url.host, “.*”, “youtube.proxysg-cache”, cache)
end

This policy was not written by me. but of course it can be used by any ProxySG administrator. Please just copy paste it into the local policy files.

How to configure per-vlan QoS in Cisco 3550 and 3560

You might think that configuring QoS in Cisco Switches will follow the same syntax. That what I thought till i started studying CCIE. Let’s See one major difference in how policing is implemented on these two platforms.

Cisco Catalyst 3550

I find the configuration of 3550 rather easier. First, you would enable QoS. second, when classifying traffic (you of course will use MQC) in the class map you match vlan id. Then you just police that traffic however you want it. Lets see a configuration for that.

mls qos
!
class-map HTTP_VLAN_10
match vlan 10
match protocol http
!
policy-map HIGH_BANDWIDTH
class HTTP_VLAN_10
set dscp af11
policy 12800 1600 exceed-action drop
!
interface fastethernet 0/1
service-policy input HIGH_BANDWIDTH

That is straight forward, and should be done easily without much confusion since that approach is what used in most routers.

Cisco Catalyst 3560

Here where we have rather different way of doing the same task. First, enable mls qos. Second, Match the interesting traffic. Third, enable mls qos on the interface. Fourth, mark the traffic in the First policy. Fifth, Police the rate at the nested policy. lastly, Apply it at the vlan interface.

mls qos
!
interface fa0/2
mls qos vlan-based
!
class-map INT
match input-interface fa0/2
!
policy-map NESTED_POLICE
class INT
policy 12800 1600 exceed-action drop
!
class-map HTTP
match protocol http
!
policy-map PARENT_MARK
class HTTP
set dscp af11
service-policy NESTED_POLICE
!
interface vlan 10
service-policy PARENT_MARK

Please note that you can’t MARK and POLICE the traffic in the same policy. So creating parent policy for marking and nested policy for rate police. We have to enable the interfaces that we want to participate in policing the vlan traffic since a direct match can’t be made. lastly, the service-policy will be applied into the Vlan interface and not the physical interface.

CCIE RS INE Topology in GNS3

Continued »

How to traffic shape Frame-Relay? – part 2

In How to traffic shape frame-relay? part 1 , i have mentioned four types of QoS mechanism that can be applied to frame-relay interface. Lets have a look at the other two methods that can be used with frame-relay networks.

MQC Frame-Relay Traffic shaping

In here, we see the efforts put into introducing the MQC style for traffic shaping. but with this method, you nest the MQC into a map-class. Yes, it doesn’t look pretty, and seems slightly confusing. But let’s have an example, and this will ease our understanding of the topic.

policy-map CBWFQ
class VOICE
priority 64
class class-default
fair-queue
!
policy-map SHAPE
class class-default
shape average 256000 2560 0
shape adaptive 128000
service-policy CBWFQ
!
map-class frame-relay TEST_DLCI
service-policy output SHAPE
!
interface Serial 0/0.1
frame-relay interface-dlci 101
class TEST_DLCI

This example lengthy as it seems, but it is still straight forward. we have defined shaping in MCQ style, then impliemented that into map-class. lastly, this map-class was configured inside the interface-dlci.

Class Based Generic Traffic Shaping

This is the last method out of the four methods that can be used for FRTS. It is similar to the legacy GTS. In this, you have the advantage to match the class based of frame-relay dlci. Lets see an example and that should show us the details.

class-map DLCI
match fr-dlci 123
!
policy-map SHAPE_123
class DLCI
shape average 256000
!
interface s0/1
service-policy output SHAPE_123

One of the main issues of this method is that adaptive shaping can’t be used, nor voice-adaptive fragmentation.

all of the four methods have their advantage and disadvantage to them. from the simplest, to more complicated ones. The situations/requirment will be the deciding factor on which method use for FRTS.

How to traffic shape Frame-Relay? – part 1

Frame-Relay Traffic shaping (FRTS) is one of the fundamental topics that is required to master before going to the CCIE lab exam. Since you never know which method will be required by the exam to do. There are four different types of methods, namely:

• Generic Traffic Shaping
• Legacy Frame-Relay Traffic Shaping
• MQC  Frame-Relay Traffic Shaping
• Class Based Generic Traffic Shaping

traffic-shape {group|rate} Peak-Rate Bc Be Queue-size

traffic-shape group 100 256000 2560 2560 16

Bc = Rate * Tc (in seconds), Tc = Bc/Rate = 2560/256000 = 0.01 second

traffic-shape adaptive CIR

traffic-shape adaptive 128000

R1(config-map-class)#frame-relay ?

adaptive-shaping   Adaptive traffic rate adjustment, Default = none

bc                 Committed burst size (Bc), Default = 7000 bits

be                 Excess burst size (Be), Default = 0 bits

cir                Committed Information Rate (CIR), Default = 56000 bps

congestion         Congestion management parameters

custom-queue-list  VC custom queueing

end-to-end         Configure frame-relay end-to-end VC parameters

fair-queue         VC fair queueing

fecn-adapt         Enable Traffic Shaping reflection of FECN as BECN

fragment           fragmentation – Requires Frame Relay traffic-shaping to be configured at the interface level

holdq              Hold queue size for VC

idle-timer         Idle timeout for a SVC, Default = 120 sec

interface-queue    PVC interface queue parameters

ip                 Assign a priority queue for RTP streams

iphc-profile       Configure IPHC profile

mincir             Minimum acceptable CIR, Default = CIR/2 bps

priority-group     VC priority queueing

tc                 Policing Measurement Interval (Tc)

traffic-rate       VC traffic rate

voice              voice options

map-class frame-relay TEST

frame-relay cir 256000

frame-relay mincir 128000

frame-relay be 0

frame-relay bc 2560

!

interface serial 1/0

frame-relay traffic-shaping

frame-relay interface-dlci 201

class TEST

!

How Rendezvous Points (RP) Chosen in Auto-RP Multicast Domain?

IP Multicast can work on Dense, or Sparse Mode. Dense, where all multicast traffic is flooded out of all the interfaces other than the one it came from (split horizon). It is easy to configure, and there are no planning with it. The down side is, it might create congestion in the network. Specially the WAN links, where every byte cost money. To tackle this issue, Sparse mode should be used.

Sparse mode, works by creating Shared-Tree that is rooted to the Rendezvous Point (RP). By default, all routers assume no one wants the multicast traffic, until they get a request for it.

To load balance the traffic, multiple RPs can be configured. But the question is, which RP will be responsible for which group of multicast streams?

The answer is simple, the RP will be chosen by Mapping Agent (MA) on the longest (most specific) Multicast group.

An example will clarify

R1(config)#ip access-list standard GROUP_1
R1(config)#deny 224.1.1.1 0.0.0.0
R1(config)#permit 224.0.0.0 7.255.255.255
R1(config)#permit 224.0.0.0 15.255.255.255
R1(config)#ip pim send-rp-announce loopback 1 scope 5 group-list GROUP_1
—————————————————————————-
R2(config)#ip access-list standard GROUP_2
R2(config)#deny 224.1.1.1 0.0.0.0
R2(config)#permit 232.0.0.0 7.255.255.255
R2(config)#permit 224.0.0.0 15.255.255.255
R2(config)#ip pim send-rp-announce loopback 1 scope 5 group-list GROUP_2

What will happen, that R1 will be the RP for group 224.0.0.0 to 231.255.255.255. while R2 for 232.0.0.0 to 239.255.255.255. Group 224.1.1.1 will have no RP, so the only way for that group to work is to be configured in Dense mode.

How to upgrade Citrix NetScaler Firmware?

How to configure route dampening in BGP

Flapping routes are bad news in BGP. flapping routes are the routes that go up and down in very short time. they are bad news cause they require changes in routing table. routing table that consists of 100 thousand routes cause high load on router. a flapping route will: 1- change the table by being removed and added. 2- change other routes that depend on that route for transition (recursive lookup).

To minimize flapping routes, two separate features can be used. First is the route summary. Second is the route dampening.

Route dampening is to suppress a prefix based on the number of flaps. each flap will have a penalty value (cost). once the route flaps, the route will be added to “history” where it will be tracked. If the suppress limited reached BGP will will suppress the route and mark it as damped. Then every 5 seconds the penalty value will be decreased by exponentially. The decrease value depends on one single parameter which is half-life. half-life = the amount of time required to make the penalty value half of the current state. The penalty for flapped route is 1000 per flap, while penalty for attribute change is 500.

The equation for the decay is

P(t) = P(0) / 2^(t/half-life); Where p(t) = reuse limit, P(0) = suppress limit.

the command syntax to apply this in BGP is

router bgp xxxxx
bgp dampening [half-life reuse suppress max-suppress-time] [route-map map-name]

The default values are half-life = 15 mins, reuse = 750, suppress = 2000, max-suppress-time=60 mins.

The route map can be used to set these values as well. The mentioned equation is important to calculate the half-time values, cause they determine how fast a flapping route can be released from the damped stated.

How to configure Path Variables for BGP aggregation route?

Using route aggregation (summary) is one of the important tools with BGP. it provides a strong foundation to keep the routes from flapping, or making rapid changes within the BGP backbone cloud. but what if we want to advertise the aggregation with different AS Path variables? as it is known BGP route can take many variables, from local-preference, weight, as-path, community values, etc.

For that, we have the attribute map a route-map that can be used to set any variable we want to the aggregation. here is the syntax

aggregate-address x.x.x.x x.x.x.x summary-only attribute-map ATTRIB

route-map ATTRIB
set community 200:200
set weight 200

it is very simple and effective. hope this post was informative.