ICMP Fragmentation and Firewall

Following an installation of new firewalls, I was facing an issue of communication between a CMC (Central Management Console) and a Riverbed Steelhead.
In a normal way, the CMC open a SSH session to push rules to the Riverbed. But after the installation, it was not working anymore. I have investigated and found the root cause of this issue.

Packets between the CMC and the Riverbed are fragmented. Without firewalls, CMC and Riverbed use PMTU in order to discover the MTU small enough to traverse the entire path without fragmentation.
In a first step, Path MTU uses the option Don't Fragment (DF). When a packet is sent with this option, it cannot been fragmented. If a router with a smaller MTU receives this packet, it will drop it and send to the sender an ICMP Fragmentation Needed. This step is repeated until the source has reached the destination without fragmentation.

As you can see below, our problem come from this ICMP Fragmentation Needed packet.
When the steelhead sends a packet (with option Don't fragment) to the CMC, a router on the path sends a ICMP fragmentation Needed. However, the new firewall filters this packet and now the handshake failed.

Workaround:

• Allow ICMP option on the firewall.
• Reduce MTU on primary interface of the Riverbed.

QoS Traffic Policing (drop excess traffic)

Today, I was facing an issue with several users. These users were uploading big files on server (http). Unfortunately, they were using all available bandwidth. It's why, I have decided to police this specific traffic (any users to this server). With the following configuration, the bandwidth for users is limited at 3Mbps (configuration applied on a Layer 3 Switch):

• If the bandwidth exceeds 3Mbps, following packets are dropped:

access-list 100 permit tcp any 10.10.10.200 0.0.0.0 eq www

!

class-map match-all UserTraffic

match access-group 100

!

policy-map policeTraffic

class UserTraffic

    police 3000000 conform-action transmit  exceed-action drop

!

interface Vlan999

service-policy output policeTraffic

• Check statistics:

MYSWITCH#show policy-map  interface vlan 999

Vlan999

  Service-policy output: policeTraffic

    Class-map:UserTraffic (match-all)

      558663 packets, 827048161 bytes

      5 minute offered rate 3643000 bps, drop rate 645000 bps

      Match: access-group 100

      police:

          cir 3000000 bps, bc 93750 bytes

        conformed 460702 packets, 679305595 bytes; actions:

          transmit

        exceeded 97962 packets, 147744080 bytes; actions:

          drop

        conformed 2994000 bps, exceed 669000 bps

    Class-map: class-default (match-any)

      1626596 packets, 568490144 bytes

      5 minute offered rate 3555000 bps, drop rate 0 bps

      Match: any

BGP Decision Process

Nothing new in this post! It's just a reminder regarding the BGP process decision:

1. Weight (Bigger win, Cisco proprietary)
2. LOCAL_PREF (Bigger Win)
3. Locally injected routes (Locally injected win overiBGP/eBGP learned)
4. AS_PATH length (Smaller Win)
5. ORIGIN (code I win over E, E win over ? )
6. MED (Smaller Win)
7. Neighbor Type (eBGP win over iBGP)
8. IGP metric to NEXT_HOP (Smaller win)