Overview

I have been seeing a number of articles on the Internet trying to persuade Cisco to offer some kind of real-time emulation software for their IOS. I remember Greg Ferro from Etherealmind started a petition a while back and I have yet to see any development on that…

The fact that the matter is, Cisco already have such platform called IOU, which is designed to emulate their IOS to a near hardware experience for their internal testing environment. (Don’t quote me on this, but this is pretty good from what I have heard, or researched)

Currently we have Dynamips, which is one of the resource hungry Cisco Hardware emulation platform where testing can be done to a certain extend but it is nowhere near perfect, and here are some facts.

• Dynamips does require a Lot of resources.
• This is extremely processor heavy.
• QoS does not work very well.

If you want to have a detailed explanation on, please have a look at the following post by Wendell Odom who explains thoroughly on the NWW.

What puzzles me is the fact that Cisco goes out of their way to promote their Educational sector, yet they are reluctant to offer some kind of Software Emulation to accommodate their IOS.

I can understand that fact that Cisco is trying to draw a line between testing and learning… When it comes to learning, it is fine. But, when it comes to Testing, Cisco might be concerned that it would affect their after sale services and revenue.

They are also maybe concerned about the lOS architecture getting onto the wrong hand. If you think about it, it does make sense because if they don’t support the Students, they would have put a stop to Dynamips

Suggestion

That is why I was wondering whether Cisco would consider releasing a pre built Topology such as the R&S 360 Lab within IOU/L2IOS (which they run on the R&S Lab for the troubleshooting section) and lock it with an encryption so it cannot be decompiled. There is still a risk on there, but it might be worth it. That way, it is only used for studying purposes and they don’t have to worry about it is being used for commercial use which might affect their after sale services…

That is why I suggest that if they released a “supersized” topology like the TS section on their RS Lab exam (with the correct IOS version), one can pretty much turn a few routers off and accommodate to the students needs.

With such topology, I personally think a student can pretty much cover CCNA/CCNP or even unto a level of a CCIP exams… If a CCNA student is overwhelmed by such topology, they can start with Packet trace and once they are comfortable, they can move onto this.

I do understand people wants such technology to test and troubleshoot, but I personally think, since they promote the 360 Learning solutions vigorously, they should consider this option to help the students.

Update

As of 21st April 2011, Cisco has finally listen to the request now offering the IOU Labs at their Cisco Learning Network Store. If you need more info, you can have a look Here

I have been working on some xDSL sync issues and and here are some of my findings to boost the xDSL Sync rate and have a stable line.

Option 1

First of all, make sure which standard your ISP’s DSLAM running on. This is important because some standards have limitations which will create a bottleneck when it comes to the hardware you are using. First rule of thumb for people who are not sure is to use the ISP’s provided hardware.

For example ITU G.992.5 (ADSL2+) will have an upload limitation of 1.3 Mbps, you might have a line which is capable of handling more than 1.3 Mbps but the hardware you use will cause a limitation. This is why you need to make sure which standard the ISP is running the DSLAM on. If the ISP happen to run ITU G.992.5 Annex M (ADSL2+ M) you are likely to get an upload speed of more than 1.3 Mbps, thus having a router which is capable of supporting Annex M will be beneficial.

Option 2

Run your ADSL line from the Master Socket. This way, you are likely to eradicate any noise on the line which will affect the DSL connection.

Option 3

It is highly advisable to remove the ringer cable on the phone line. This cable causes a lot of noise on the line and no longer required because the DSL Micro-Filter takes care of the ringer.
Only connect the wires on (2) and (5) on the BT NTE5 box and disconnect all the other wires. This way, there will be no static looping back via the ringer cable.

I would recommend going through all three Options above to make sure those are ticked and If you require any further assistance, I recommend you to do a Google Search and there are plenty of information out there which explains in more detail.

This procedure is quite simple and the following is done on Linux. When you have an uncompressed IOS, you don’t need to wait for it when it comes to loading it on Dynamips.

unzip -p c3725-adventerprisek9-mz.124-25.bin > c3725-adventerprisek9-mz.124-25.image

You can see both compressed and uncompressed versions below.

Workstation IOS # ls -ltrh |grep 3725
-rw-r--r-- 1 root root 38M 2010-11-29 16:47 c3725-adventerprisek9-mz.124-25.bin
-rw-r--r-- 1 root root 79M 2010-11-29 20:23 c3725-adventerprisek9-mz.124-25.image
Workstation IOS #

Before you read through this post, I assume you have got at least the basic understanding of BGP and how it works.

Here are some facts:

BGP is a path vector Routing Protocol works on TCP port 179.

Neighbor with the lowers IP address will establish the connection to the Remote Peer on TCP port 179 with a random source port.

In this case, the Remote Peer will become the Server and the Local Peer will become the client. This peering relationship will change when we clear the BGP process on either peer or the underlying BGP connection get severed for any reason.

In case you want to specifically want to set one Peer as the Server and one as the Client, the IOS does support it.

This is how it is done…

R1 and R2 have a eBGP peering where R1 is on AS 100 and R2 is on 200.

R1#sh run | s bgp
router bgp 100
no synchronization
bgp router-id 1.1.1.1
bgp log-neighbor-changes
redistribute connected
neighbor 10.0.0.2 remote-as 200
no auto-summary
R1#

R2#sh run | s bgp
router bgp 200
no synchronization
bgp router-id 2.2.2.2
bgp log-neighbor-changes
redistribute connected
neighbor 10.0.0.1 remote-as 100
no auto-summary
R2#

If you are wondering, I am redistribution the connected routes because I want to make sure the BGP is in-fact exchanging prefixed. (I don’t fully trust Dynamips when it comes to emulation… )

As you can see below, here are the BGP connection info…

R1#sh ip bgp neighbors 10.0.0.2 | i host|state
BGP state = Established, up for 01:27:40
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Local host: 10.0.0.1, Local port: 46257
Foreign host: 10.0.0.2, Foreign port: 179
R1#

R2#sh ip bgp neighbors 10.0.0.1 | i host|state
BGP state = Established, up for 01:28:07
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Local host: 10.0.0.2, Local port: 179
Foreign host: 10.0.0.1, Foreign port: 46257
R2#

As you can see above, R1 is the Client and R2 is the Server (As you can see, the Local port is 179)

As you can see below, I have cleared the BGP session and the peering arrangement is changed from R1 being the Client to Server…

R1#sh ip bgp neighbors 10.0.0.2 | i host|state
BGP state = Established, up for 00:00:31
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Local host: 10.0.0.1, Local port: 179
Foreign host: 10.0.0.2, Foreign port: 62021
R1#

R2#sh ip bgp neighbors 10.0.0.1 | i host|state
BGP state = Established, up for 00:00:06
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Local host: 10.0.0.2, Local port: 62021
Foreign host: 10.0.0.1, Foreign port: 179
R2#

In case, you want to hard-code one Peer as Client and another Peer as Server. This is possible under the Cisco IOS. I have never seen such configuration on Production Environment but this will come in handy when we have some kind of firewalling on one side of the peer or we want to specifically set which neighbor becomes the Server and which becomes the Client.

This is accomplished under the neighbor statement and I will be configuring R1 as Server and R2 as the Client. On the command itself, Active being the Client and Passive being the Server.

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#router bgp 100
R1(config-router)#neighbor 10.0.0.2 transport connection-mode ?
active   Actively establish the TCP session
passive  Passively establish the TCP session

R1(config-router)#neighbor 10.0.0.2 transport connection-mode passive
R1(config-router)#

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#router bgp 200
R2(config-router)#neighbor 10.0.0.1 transport connection-mode ?
active   Actively establish the TCP session
passive  Passively establish the TCP session

R2(config-router)#neighbor 10.0.0.1 transport connection-mode active
R2(config-router)#

Now I have Cleared the BGP session numerous times and as you can see below, the Client / Server relationship is not changed.

R1#sh ip bgp neighbors 10.0.0.2 | i host|state
BGP state = Established, up for 00:02:24
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Local host: 10.0.0.1, Local port: 179
Foreign host: 10.0.0.2, Foreign port: 14953
R1#

R2#sh ip bgp neighbors 10.0.0.1 | i host|state
BGP state = Established, up for 00:01:22
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Local host: 10.0.0.2, Local port: 14953
Foreign host: 10.0.0.1, Foreign port: 179
R2#

I have came across a lot of BGP configurations where there are lot of the configurations can be optimized. But having said that, this is not always the case when the Network is being built gradually.

Here is a couple of them, called Peer Session Templates and Peer Policy Templates; which we can use in such BGP configuration optimisations, when we…

1. Design a Network from scratch.
2. Design with a future overview.

These configurations can be used when it comes to commands which are session specific.

• description
• disable-connected-check
• ebgp-multihop
• exit peer-session
• inherit peer-session
• local-as
• password
• remote-as
• shutdown
• timers
• translate-update
• update-source
• version

I wouldn’t personally set password on a template, because…

1. You might want to have a different password for a specific peer because it is controlled by some other Administrative body.
2. In my opinion, it is best practice to set the password per peer than to have it under a template.

Here is an example configuration from

As of 5th May 2010 All 13 DNS ROOT Server will consist of a signed digital signature with every replied query. This has been ruled out to tackle any man-in-middle attack similar to Dan Kaminsky’s exploit.

Is it going to break the internet?

It is only going to affect if the firewalls & FWSM are not configured correctly to allow DNSSEC signed packets.

The answer being, as we already know DNS uses UDP packets for query replies; and most firewalls are going to drop any packets larger than 512bytes.

Having been said, the DNSSEC signed replies are going to have an extra layer of encryption, thus increasing the packet size up to 4KB (4096) and the firewalls & FWSMs needs to be configured to allow such larger packets through.

What needs to be configured on the Firewall?

The firewall needs to have the following settings to allow larger UDP packets through…

message-length maximum 4096

We can either hard-code the maximum-length or use other methods to tackle this issue.

More info about DNSSEC can be found on http://www.root-dnssec.org or simply typing the word on Google.

I have come across an odd scenario on pre-share key based IPSec tunnels…

The question being, when an IPSec tunnel is active (Phase 1 and 2 are UP) and the pre-share key is changed, does this tear down the tunnel?

The tunnel configuration on R4 follows…

!
crypto isakmp policy 1
 encr aes 256
 hash md5
 authentication pre-share
 group 2
crypto isakmp key fnode address 192.168.1.5
!
!
crypto ipsec transform-set FNODE1 esp-3des esp-sha-hmac
!
crypto map FNODE1 1 ipsec-isakmp
 set peer 192.168.1.5
 set transform-set FNODE1
 match address 120
!

!
interface Ethernet0/0
 ip address 192.168.1.4 255.255.255.0
 full-duplex
 crypto map FNODE1
!

access-list 120 permit ip 192.168.1.0 0.0.0.255 192.168.1.0 0.0.0.255
!

The tunnel configuration on R5 follows…

!
crypto isakmp policy 1
 encr aes 256
 hash md5
 authentication pre-share
 group 2
crypto isakmp key fnode address 192.168.1.4
!
!
crypto ipsec transform-set FNODE1 esp-3des esp-sha-hmac
!
crypto map FNODE1 1 ipsec-isakmp
 set peer 192.168.1.4
 set transform-set FNODE1
 match address 120
!

!
interface Ethernet0/0
 ip address 192.168.1.5 255.255.255.0
 full-duplex
 crypto map FNODE1
!

access-list 120 permit ip 192.168.1.0 0.0.0.255 192.168.1.0 0.0.0.255

Bringing the tunnel up by pinging the Peer from R4

R4#ping 192.168.1.5 so e0/0

As you can see below, the Tunnel is now UP/UP, and 4 packets have been encrypted / decrypted.

R4#sh cry isa sa
dst             src             state          conn-id slot status
192.168.1.5     192.168.1.4     QM_IDLE              1    0 ACTIVE

R4#
R4#sh cry ip sa

interface: Ethernet0/0
    Crypto map tag: FNODE1, local addr 192.168.1.4

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0)
   remote ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0)
   current_peer 192.168.1.5 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4
    #pkts decaps: 4, #pkts decrypt: 4, #pkts verify: 4
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 1, #recv errors 0

     local crypto endpt.: 192.168.1.4, remote crypto endpt.: 192.168.1.5
     path mtu 1500, ip mtu 1500
     current outbound spi: 0x82E8BCA5(2196290725)

     inbound esp sas:
      spi: 0x267E7582(645821826)
        transform: esp-3des esp-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 2001, flow_id: 1, crypto map: FNODE1
        sa timing: remaining key lifetime (k/sec): (4484045/3526)
        IV size: 8 bytes
        replay detection support: Y
        Status: ACTIVE

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:
      spi: 0x82E8BCA5(2196290725)
        transform: esp-3des esp-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 2002, flow_id: 2, crypto map: FNODE1
        sa timing: remaining key lifetime (k/sec): (4484045/3524)
        IV size: 8 bytes
        replay detection support: Y
        Status: ACTIVE

     outbound ah sas:

     outbound pcp sas:
R4#

Lets change the Pre-Share Key on R4

R4(config)#no crypto isakmp key fnode address 192.168.1.5
R4(config)#
R4(config)#crypto isakmp key fnode@@@_@ address 192.168.1.5

Now, I have changed the key and pinged the remote peer again… Then checked whether the tunnel has gone down…?

As you can see below, there were 9 packets been encrypted and decrypted and tunnel is still UP/UP!

R4#sh cry isa sa
dst             src             state          conn-id slot status
192.168.1.5     192.168.1.4     QM_IDLE              1    0 ACTIVE

R4#

R4#sh cry ip sa | i pkts
    #pkts encaps: 9, #pkts encrypt: 9, #pkts digest: 9
    #pkts decaps: 9, #pkts decrypt: 9, #pkts verify: 9
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
R4#

Now, we will clear ISAKMP and Crypto MAP…

R4#clear cry isa
R4#clear crypto sa map FNODE1

Now, as we expect, the tunnel is brought down…

R4#sh cry isa sa
dst             src             state          conn-id slot status

R4#

R4#sh cry ipsec sa

interface: Ethernet0/0
    Crypto map tag: FNODE1, local addr 192.168.1.4

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0)
   remote ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0)
   current_peer 192.168.1.5 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
    #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 0, #recv errors 0

     local crypto endpt.: 192.168.1.4, remote crypto endpt.: 192.168.1.5
     path mtu 1500, ip mtu 1500
     current outbound spi: 0x0(0)

     inbound esp sas:

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:

     outbound ah sas:

     outbound pcp sas:
R4#

As expected, when we sent interesting traffic, the tunnel did not come up due to mis-match of pre-share key… “MM_KEY_EXCH”

R4#sh cry isa sa
dst             src             state          conn-id slot status
192.168.1.5     192.168.1.4     MM_KEY_EXCH          1    0 ACTIVE

R4#

Now, we set the key back to the original one…

R4(config)#no crypto isakmp key fnode@@@_@ address 192.168.1.5
R4(config)#crypto isakmp key fnode address 192.168.1.5

As expected, the tunnel comes back up when we sent interesting traffic…

R4#sh cry ip sa

interface: Ethernet0/0
    Crypto map tag: FNODE1, local addr 192.168.1.4

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0)
   remote ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0)
   current_peer 192.168.1.5 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4
    #pkts decaps: 4, #pkts decrypt: 4, #pkts verify: 4
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 6, #recv errors 0

     local crypto endpt.: 192.168.1.4, remote crypto endpt.: 192.168.1.5
     path mtu 1500, ip mtu 1500
     current outbound spi: 0xE15525F6(3780453878)

     inbound esp sas:
      spi: 0x3D15E740(1024845632)
        transform: esp-3des esp-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 2002, flow_id: 2, crypto map: FNODE1
        sa timing: remaining key lifetime (k/sec): (4578721/3577)
        IV size: 8 bytes
        replay detection support: Y
        Status: ACTIVE

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:
      spi: 0xE15525F6(3780453878)
        transform: esp-3des esp-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 2001, flow_id: 1, crypto map: FNODE1
        sa timing: remaining key lifetime (k/sec): (4578721/3576)
        IV size: 8 bytes
        replay detection support: Y
        Status: ACTIVE

     outbound ah sas:

     outbound pcp sas:
R4#

The fact of the matter is, whenever there is a change is pre-share key and such, the tunnel MUST be cleared to take effect, otherwise it will _not_ come back up.

In another word, when there is an active tunnel and such modifications are made to the configuration, clearing ISAKMP and Crypto MAP is a must.

OSPF Loopback interfaces are treated as a stub host and will only have a 32 bit host route on the other devices no matter how the subnet mask is entered under the OSPF network statement.

We will explore how we can disable this default behaviour using a few methods.

As you can see, R4 is configured with IP address 192.168.1.4 and R5 with 192.168.1.5.

We have loopback interfaces added with /24 subnet masks on R4 and R5

R4#sh run int loop0
Building configuration...
Current configuration : 61 bytes
!
interface Loopback0
ip address 4.4.4.4 255.255.255.0
end
R4#

R5#sh run int loop 0
Building configuration...
Current configuration : 61 bytes
!
interface Loopback0
ip address 5.5.5.5 255.255.255.0
end
R5#

We are running basic OSPF Configs as follows…

R4#sh run | se router ospf 1
router ospf 1
router-id 4.4.4.4
log-adjacency-changes
network 4.4.4.0 0.0.0.255 area 0
network 192.168.1.0 0.0.0.255 area 0
R4#

R5#sh run | se router ospf 1
router ospf 1
router-id 5.5.5.5
log-adjacency-changes
network 5.5.5.0 0.0.0.255 area 0
network 192.168.1.0 0.0.0.255 area 0
R5#

This is what we are seeing on R4 and R5 and we expected this…

R5#sh ip ro ospf
4.0.0.0/32 is subnetted, 1 subnets
O       4.4.4.4 [110/11] via 192.168.1.4, 00:12:27, Ethernet0/0
R5#

R4#sh ip ro ospf
5.0.0.0/32 is subnetted, 1 subnets
O       5.5.5.5 [110/11] via 192.168.1.5, 00:12:43, Ethernet0/0
R4#

Now we will try the first method, this is to set the OSPF Network type to point-to-point under the interface configuration mode.

R4#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R4(config)#int loop 0
R4(config-if)#ip ospf network point-to-point
R4(config-if)#

R5#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R5(config)#int loop0
R5(config-if)#ip ospf network point-to-point
R5(config-if)#

As you can see this works, and now we are seeing the whole /24 Range…

R4#sh ip ro ospf
5.0.0.0/24 is subnetted, 1 subnets
O       5.5.5.0 [110/11] via 192.168.1.5, 00:00:04, Ethernet0/0
R4#

R5#sh ip ro ospf
4.0.0.0/24 is subnetted, 1 subnets
O       4.4.4.0 [110/11] via 192.168.1.4, 00:00:18, Ethernet0/0
R5#

Second option we got is to redistribute the connected network with the with the redistribute connected subnets under the Router OSPF configuration mode.

When it comes to redistribution, try not to go wild and it is always a good idea to create route-map to point out what you want redistributed.

R4#sh ip ro ospf
5.0.0.0/24 is subnetted, 1 subnets
O E2    5.5.5.0 [110/20] via 192.168.1.5, 00:00:00, Ethernet0/0
R4#

R5#sh ip ro ospf
4.0.0.0/24 is subnetted, 1 subnets
O E2    4.4.4.0 [110/20] via 192.168.1.4, 00:00:15, Ethernet0/0
R5#

The third option we have is to use the Area Range command. To accomplish this, we will need to add a few more Loopback interfaces on R4 then we will use the area x range command to summarise it.

R4#sh ip int brie | i up
Ethernet0/0    192.168.1.4     YES manual up     up
Loopback0      4.4.4.4         YES manual up     up
Loopback10     10.1.1.1        YES manual up     up
Loopback11     11.1.1.1        YES manual up     up
Loopback12     12.1.1.1        YES manual up     up
R4#

When we add the loopback interfaces into OSPF, it is still showing it as a /32 Host route…

R5#sh ip ro ospf
10.0.0.0/32 is subnetted, 1 subnets
O IA    10.1.1.1 [110/11] via 192.168.1.4, 00:00:22, Ethernet0/0
11.0.0.0/32 is subnetted, 1 subnets
O IA    11.1.1.1 [110/11] via 192.168.1.4, 00:00:12, Ethernet0/0
12.0.0.0/32 is subnetted, 1 subnets
O IA    12.1.1.1 [110/11] via 192.168.1.4, 00:00:12, Ethernet0/0
R5#

Now, we will use the Area 1 Range command to summarise it on R4. Once it is done, we can now see the end result.

Note: The above Loopback networks have been added into Area 1 under the Router OFPF configuration.

R5#sh ip ro ospf
O IA 8.0.0.0/5 [110/11] via 192.168.1.4, 00:00:10, Ethernet0/0
R5#

These are the three method I know of when it comes to disabling the /32 host route on OSPF Loopback Networks…

I was going through 6to4 tunnel configs and thought I’d post some info on converting IPv4 address into IPv6 Address. This is pretty straight forward and its obviously involves HEX conversion.

Method 1 (Please also see Method 2 below as I think it is much more easier)

Here, I will convert the address 192.168.25.234

First we divide each octet by 16 and write down the remainder, primary school maths!

192 ÷ 16 = 12 remainder 0
168 ÷ 16 = 10 remainder 8
25 ÷ 16 = 1 remainder 9
234 ÷ 16 = 14 remainder 10

We also know that HEX has the following Values

A = 10
B = 11
C = 12
D = 13
E = 14
F = 15

So we can write 192.168.25.234 into HEX like so… C0A8:19EA

Now we will change the HEX Address C0A8:19EA into regular IPv4

C0 = (12 x 16) + 0 = 192
A8 = (10 x 16) + 8 = 168
19 = (1 x 16) + 9 = 25
EA = (14 x 16) + 10 = 234

QED

Method 2

Another easier way to convert is to convert the octets into Binary, in this case we will still use the IP address 192.168.25.234

Split those above 32Bit into equal 16 Bits as HEX is based on Base of 16, then Add them up.

C0
A8
19
EA

Hope I have explained it thoroughly so you could follow… If you have any doubts, feel free to add your comments.

I was going through some TCP windowing over a high speed WAN link, and thought it might be worth to post some info regarding this.

We do face a typical problem of having slow speed file transfer even if the dedicated pipe is capable of supporting it.

There are three factors which affects this…

1. TCP Window Size.
2. Round trip latency of the circuit.
3. Bandwidth of the circuit.

Maximum throughput you can get from a line with 10ms latency and a TCP window of 32KB can be calculated with…

32KB –> 32 x 1024 x 8 = 262144 Bits

262144 ÷ 0.01 = 26214400 bps = 26.2144 Mbps

Let’s say we have an OC-3 line, which is at 155 Mbps and a round trip latency of 10ms, and we need to calculate the TCP window size to maximize the throughput…

155.52 x 10⁶ = 155520000 bps

TCP_WINDOW = 155520000 x 0.01 = 1555200 Bits = 194400 Bytes = 189.84375 KB

Hope I got the calculation right