Friday, February 28, 2014
Tuesday, December 17, 2013
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:
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.
Saturday, December 14, 2013
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
Tuesday, December 3, 2013
BGP Decision Process
Nothing new in this post! It's just a reminder regarding the BGP process decision:
- Weight (Bigger win, Cisco proprietary)
- LOCAL_PREF (Bigger Win)
- Locally injected routes (Locally injected win overiBGP/eBGP learned)
- AS_PATH length (Smaller Win)
- ORIGIN (code I win over E, E win over ? )
- MED (Smaller Win)
- Neighbor Type (eBGP win over iBGP)
- IGP metric to NEXT_HOP (Smaller win)
Tuesday, November 26, 2013
Key Based SSH Authentication on a Linux Host using Putty
In order to be more secure, I have decided to use a key instead of a password authentication. I'm using putty to connect to my linux server. I have used the following steps in order to configure it:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
After this, if you open the session, you will be directly prompted to the linux host.
- Generate a public and private key with PuTTYgen (click on Generate):
- Save the public and private key.
- The next step is to add the public key on the server:
chmod 700 ~/.ssh
- Paste the public key to the following file:
chmod 600 ~/.ssh/authorized_keys
- Configure the putty session:
- Create a new session and save it:
- Select data and configure 'Auto-login' (usersame used by the created key):
- Configure the path to the private key:
After this, if you open the session, you will be directly prompted to the linux host.
Monday, November 25, 2013
OSPF Database Reminder in the same area
This is a reminder in order to interpret an ospf database on a Cisco router. I have created the following lab to test the 'show ip ospf datase':
In red, the router ID:
R3#show ip ospf database
OSPF Router with ID (3.3.3.3) (Process ID 1)
The list of all routers in the area:
Router Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Link count
1.1.1.1 1.1.1.1 129 0x80000002 0x0057AC 1
2.2.2.2 2.2.2.2 25 0x80000003 0x00536B 2
3.3.3.3 3.3.3.3 24 0x80000002 0x0016B6 2
All the network segments in the area and the DR for each segment. Here, 10.1.2.2 is the IP address of the DR on the segment and 2.2.2.2 is the router id:
Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
10.1.2.2 2.2.2.2 103 0x80000001 0x0021F5
10.1.4.2 2.2.2.2 25 0x80000001 0x006F9D
Each subnet, even if there is no OSPF neighbor:
R1#show ip ospf database internal
OSPF Router with ID (1.1.1.1) (Process ID 1)
Stub Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Mask
10.1.2.255 1.1.1.1 355 0x0 0x006D69 /24
10.1.3.255 2.2.2.2 98 0x0 0x00448D /24
10.1.4.255 2.2.2.2 315 0x0 0x003997 /24
10.1.5.255 3.3.3.3 230 0x0 0x0010BB /24
In red, the router ID:
R3#show ip ospf database
OSPF Router with ID (3.3.3.3) (Process ID 1)
The list of all routers in the area:
Router Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Link count
1.1.1.1 1.1.1.1 129 0x80000002 0x0057AC 1
2.2.2.2 2.2.2.2 25 0x80000003 0x00536B 2
3.3.3.3 3.3.3.3 24 0x80000002 0x0016B6 2
All the network segments in the area and the DR for each segment. Here, 10.1.2.2 is the IP address of the DR on the segment and 2.2.2.2 is the router id:
Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
10.1.2.2 2.2.2.2 103 0x80000001 0x0021F5
10.1.4.2 2.2.2.2 25 0x80000001 0x006F9D
Each subnet, even if there is no OSPF neighbor:
R1#show ip ospf database internal
OSPF Router with ID (1.1.1.1) (Process ID 1)
Stub Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Mask
10.1.2.255 1.1.1.1 355 0x0 0x006D69 /24
10.1.3.255 2.2.2.2 98 0x0 0x00448D /24
10.1.4.255 2.2.2.2 315 0x0 0x003997 /24
10.1.5.255 3.3.3.3 230 0x0 0x0010BB /24
Subscribe to:
Posts (Atom)