Archives for category: Routers

IPv4 MTU issues can be hard to spot initially, there is a solution and its called Path MTU Discovery (RFC1191). The RFC describes it as the following “a technique for using the Don’t Fragment (DF) bit in the IP header to dynamically discover the PMTU of a path”

Further to that the RFC states “The basic idea is that a source host initially assumes that the PMTU of a path is the (known) MTU of its first hop, and sends all datagrams on that path with the DF bit set. If any of the datagrams are too large to be forwarded without fragmentation by some router along the path, that router will discard them and return ICMP Destination Unreachable messages with a code meaning “fragmentation needed and DF set” (Type 3, code 4)

The unfortunate issue is that the message that’s sent back doesn’t actually say what the MTU is.

A colleague of mines who is a Windows 7 expert, has reliably informed me that by default Windows 7 has PMTUD enabled.

The important point to focus on is the ICMP unreachable (Type 3, code 4). To put this quite simply, if you don’t receive an ICMP message back with the code for fragmentation needed then, your PC will assume that the MTU is fine and continue to send the packets even though somewhere in the path the packets are potentially being dropped.

There can be a number of reasons for this, including firewalls blocking the message, ICMP unreachable disabled on an interface, a transparent host between 2 endpoints (Often done in service provider networks) that has a lower MTU value.

I recently ran into an issue where IP connectivity between 2 sites looked to be fine, ping, traceroute and SSH were all working, but certain applications and protocols were not, most notably HTTPS.

Below I will explain how to spot this issue.

Take a look at the diagram below, i have deliberately used a transparent device as its most likely what you might see in a L3VPN (MPLS) network. The last mile provider provides a layer 2 path (perhaps a L2TPv3) from CE to PE and the underlying hops are hidden from us.  From the service provider perspective the routers are directly connected.

This is perhaps where an MTU issue has occurred. For this scenario I have reduced it quite significantly for effect.

Capture3

Lets say for example you have a perfectly functioning network where MTU is fine along the path. Initially you can send a ping with 1460bytes and you will get a reply. Lets increase this to something we know is to big (1550bytes). This works great in a perfectly functioning network where you receive an ICMP type 3, you will get the “packet needs to be fragmented but DF set” message.

Capture2

Now lets try that through our network where the MTU is set lower but the sending device doesn’t know about it.

Capture4

At first you think its OK because you can ping along the path and get a reply, you try SSH and it works too. Now lets try to ping with different MTU sizes. Remember your PC doesn’t receive the ICMP message this time, so what happens is you get a “request timed out” message.

Capture5

The reason for that is the packet is being dropped and the ICMP message isn’t being returned. If I ping with an MTU that is lower than the 1000 i get a reply.

Capture6

Now the question, why would HTTPS not work? well in some cases web applications or your client might set the Do Not Fragement bit in the IP header SYN request. This means the packet should not be fragmented, so when we send this on our network with the bad MTU in the path, the packet is dropped and the sending device never receives the ICMP message. It never knows that it has to reduce the MTU value. The packet capture below shows where the DF bit is set.

Capture7

I had a look through the RFC2246 for TLS1.0 and it doesn’t specify that the DF bit should be set. It’s most likely a vendor or O/S specific setting, so your observed results may differ from vendor to vendor.

RH

Did you know that OSPF neighbors do not move to the  FULL state with mismatched MTU?

I found this out at the weekend when I was working on some Data Centre switches, within the fabric these switches use jumbo MTU. So when I tried to peer a device that was not part of the fabric, I got stuck in EXSTART.

At first I was wondering if I had the OSPF configuration. I checked and double checked but all looked good.

Solved!

run “debug ip ospf adj” you will get a message similar to this.

*Nov 16 21:30:45.551: OSPF-1 ADJ Gi0/0: Nbr 10.1.1.1 has smaller interface MTU

Answer: match the MTU on both sides.
I had a read through TCP/IP Volume 1, It doesn’t mention MTU size anywhere. RFC 2328 does mention it.

If the Interface MTU field in the Database Description packet
indicates an IP datagram size that is larger than the router can
accept on the receiving interface without fragmentation, the
Database Description packet is rejected.

This is where wireshark comes in handy, I had to see this for myself.

The MTU isnt sent in the Hello packet its sent in the type 2 DBD packet, this is after the neighbors acknowledge each other (2WAY). See below.

mtu-ospf

Interesting

RH

Some time ago I setup SIP trunking , I had to configure voice translation rules on the CUBE. Here’s are a few I setup that might help you (numbers changed). Once the numbers were translated they would match dial-patterns and be routed respectively.

Using regular expression.

Number 1 translates an incoming call to a 4 digit extension.

voice translation-rule 1
rule 1 /^02081234567/ /1111/

R1#test voice translation-rule 1 02081234567
Matched with rule 1
Original number: 02081234567 Translated number: 1111

Number 2 takes any number and adds a 9 to the beginning.

voice translation-rule 2
rule 1 /^.*/ /9\0/

R1#test voice translation-rule 2 02081234567
Matched with rule 1
Original number: 02081234567 Translated number: 902081234567

Number  3 translates a dialed number beginning with +44 or + to 90 or 900.

voice translation-rule 3
rule 1 /^\+44/ /90/
rule 2 /^\+/ /900/

R1#test voice translation-rule 3 +442081234567
Matched with rule 1
Original number: +442081234567 Translated number: 902081234567

R1#test voice translation-rule 3 +1123456789
Matched with rule 2
Original number: +1123456789 Translated number: 9001123456789

Number 4 translates a 4 digit number beginning with 5, drops the 5 and appends a country code and an area code.

voice translation-rule 4
rule 1 /^5\(…$\)/ /00442081234\1/

R1#test voice translation-rule 4 5678
Matched with rule 1
Original number: 5678 Translated number: 00442081234678

Number 5 translates any number beginning with 901* to 0044 and any number beginning with 900* drops the 9.

R1#test voice translation-rule 5 9020812345678
Matched with rule 1
Original number: 9020812345678 Translated number: 004420812345678

R1#test voice translation-rule 5 90012345678910
Matched with rule 2
Original number: 90012345678910 Translated number: 0012345678910

RH

It’s worth making some notes on this subject to clear up a few misconceptions I found online.

Firstly I setup a lab to confirm what i’m about to say, the reason we use this command is to allow QoS to correctly classify or view the packets based on the original header, if the packet is encapsulated  it’s  treated the same as any other encapsulated packet. The original header and its QoS value is now unknown to the forwarding device.

So by enabling this command we can apply the classification before the encapsulation or tunneling happens.

Apply the command “qos pre-classify” to a tunnel interface, a crypto-map or a virtual tunnel interface.

Classification based on layer3 and layer4 information is the exact reason we would consider using this feature, classification based on TOS or DSCP values do not need to use this feature, that’s because of TOS byte preservation inherently built into IPSEC.

Once you’ve added the pre-classify command, apply a service-policy to the physical interface outbound, then all IP packets will be classified pre-encapsulation on any tunnels egressing that physical interface. In other words you will see hits on the policy-map individual classes.

A really great resource I found online is this QoS values calculator check it out………….

http://www.netcontractor.pl/blog/?p=371

RH

This post will show you how to configure a DHCP scope on your Cisco device.

DHCP uses the transport layer protocol UDP. DHCP server uses port 67 and the client uses port 68. DHCP would fall into layer 7 application layer protocols.

Create your pools just like below and add any options in you require i’ve shown 2 different option types one is IP and one is ASCII. You can add as many options as you need.

ip dhcp pool vlan10
network 10.10.10.0 255.255.255.0
update dns both override
domain-name mydomain.com
dns-server 10.1.1.111 10.2.2.222
netbios-name-server 10.1.1.111 10.2.2.222
default-router 10.10.10.1
option 137 ascii http://myserver.com/update
option 150 ip 192.168.101.1
lease 3
!
ip dhcp pool vlan16
network 10.10.16.0 255.255.255.0
update dns both override
domain-name mydomain.com
dns-server 10.1.1.111 10.2.2.222
netbios-name-server 10.1.1.111 10.2.2.222
default-router 10.10.16.1
option 150 ip 192.168.101.1
option 137 ascii http://myserver.com/update
lease 3
!

To add static DHCP reservations you need to add the MAC address as below. Note they start with ’01’ and in dotted hexadecimal. The ’01’ means that its Ethernet media type.

ip dhcp pool static-user1
host 10.10.10.54 255.255.255.0
client-identifier 01bb.cccc.dddd.ff
!
ip dhcp pool staticuser2
host 10.10.16.53 255.255.255.0
client-identifier 01xx.yyyy.zzzz.aa

The above configuration would be added to your switch that contains your SVI’s.

Confirm your configuration by using these commands below.

show ip dhcp binding – This will show all assigned IP’s and MAC address.
show ip dhcp pool [pool name] – This will show information on number of IP’s leased.
show ip dhcp conflict – This will show any conflicts in your pools.
clear ip dhcp binding | conflict [x.x.x.x] | * – This will clear the pool of the address you specify or all in the case of *.

DHCP

RH

Neighbours with the lowest BGP router identifier will establish the connection to the remote peer via TCP port 179, the source port will be random. We can modify this behaviour with a few simple commands.

For example we want R1 to be a passive peer. That means that R2 and R3 will actively look to establish the session.

BGP

BGP

So from R1 if we leave everything as default then we can work out that R1 it the lowest router identifier, courtesy of a loop-back interface which is 10.4.1.1. So it will look to actively establish the connection with any configured peers.

R1#sh ip bgp summary
BGP router identifier 10.4.1.1, local AS number 500

We can verify this with the following command.

R1#sh ip bgp neighbors | i host
Local host: 150.1.1.2, Local port: 57717
Foreign host: 150.1.1.1, Foreign port: 179
Local host: 150.1.1.6, Local port: 63542
Foreign host: 150.1.1.5, Foreign port: 179

Lets modify this behaviour, use the commands.

router bgp 500
 neighbor 150.1.1.1 transport connection-mode passive
 neighbor 150.1.1.5 transport connection-mode passive

Then clear the BGP session with clear ip bgp *

Now use the same command as before.

R1#sh ip bgp neighbors | i host
Local host: 150.1.1.2, Local port: 179
Foreign host: 150.1.1.1, Foreign port: 34121
Local host: 150.1.1.6, Local port: 179
Foreign host: 150.1.1.5, Foreign port: 32711

This shows us that foreign host has established the bgp connection sourcing from random port to port 179 on our local router.

RFC4271 which is the holy grail for BGP-4 states that.

8.2.1
When a BGP speaker is configured as active,
it may end up on either the active or passive side of the connection
that eventually gets established.  Once the TCP connection is
completed, it doesn’t matter which end was active and which was passive.
The only difference is in which side of the TCP connection has port number 179.

There exists a period in which the identity of the peer on the other
end of an incoming connection is known, but the BGP identifier is not
known.  During this time, both an incoming and outgoing connection
may exist for the same configured peering.  This is referred to as a
connection collision.

Interesting.

RH

4-Byte Autonomous System Number provides us with 4.3billion unique ASN’s , going far beyond the original 2-Byte range of 65536.

So what happens when you have a router that doesn’t yet support 4-Byte ASN? I’ll show you what to do.

You wouldn’t necessarily be configuring all 3 routers in the real world.

First see the simple topology below

4-Byte ASN

4-Byte ASN

R3 in the middle is still using a 2-Byte ASN and the IOS doesn’t support 4-Byte ASN. So for this exact purpose IANA assigned a placeholder, AS23456 which is used by the older routers to communicate with new 4-Byte AS numbers.

This is achieved by using a transitive BGP attribute  NEW_AS_PATH and NEW_AGGREGATOR, much like the ATOMIC_AGGREGATOR used when summarising similar routes. This stores like a small note of the actual 4-Byte ASN which is then used by the 4-Byte capable router. Something you might want to note is the AS_PATH length is also maintained, I will demonstrate this.

This particular method is known as AS-PLAIN

So on R2 and R3 setup BGP, the only difference is on R3 instead of using the actual AS number use the placeholder AS23456.

R2#sh run | sec router bgp
router bgp 132678
 bgp log-neighbor-changes
 network 111.111.111.0 mask 255.255.255.0
 neighbor 192.168.5.1 remote-as 500
no auto-summary
!
R3#sh run | sec router bgp
router bgp 500
 no synchronization
 bgp log-neighbor-changes
 neighbor 192.168.1.1 remote-as 23456
 neighbor 192.168.5.2 remote-as 23456
 no auto-summary

Now on R1 I’ve used AS_PATH Prepend to demonstrate the fact that the AS_PATH length doesn’t change, On my route map I prepended the AS path 4 times

R1#sh run | sec router bgp
router bgp 131456
 bgp log-neighbor-changes
 network 222.222.222.0
 neighbor 192.168.1.2 remote-as 500
 neighbor 192.168.1.2 route-map prepend-AS out
no auto-summary

Now lets confirm the configurations above, using the commands SH IP BGP” from R3. We will expect to see the placeholder ASN23456

   Network          Next Hop            Metric LocPrf Weight Path
*> 111.111.111.0/24 192.168.5.2              0             0 23456 i
*> 222.222.222.0    192.168.1.1              0             0 23456 23456 23456 23456 23456 i

Now  let’s do the same from R2 , we should now expect to see the 4-Byte ASN in the AS_PATH.

     Network          Next Hop            Metric LocPrf Weight Path
 *>  111.111.111.0/24 0.0.0.0                  0         32768 i
 *>  222.222.222.0    192.168.5.1                            0 500 131456 131456 131456 131456 131456 i

To see exactly what is sent between the router’s I’ve used Wireshark to capture the packets, you can see the message sent from R3, AS_PATH and NEW_AS_PATH

Wireshark Capture

Wireshark Capture

 

If you need to work out the ASDOT version of an ASPLAIN 4-Byte ASN use the examples below.

4-Byte ASN-194534
1. 194534 / 65535 = 2 (integer)
2. 194534 – ( 65535 * 2) = 63464
3. 63464 – 2 (integer) = 63462
4  ASDOT = 2.63462

Here is a different example this time with an even longer ASN

4-Byte ASN-2394951
1. 2394951 / 65535 = 36 (integer)
2. 2394951 -(65535*36) = 2394951-2359260 = 35691
3. 35691-36 (integer) = 35655
4. ASDOT =36.35655

RH