Showing posts with label optimization. Show all posts
Showing posts with label optimization. Show all posts

Wednesday, November 14, 2012

ISIS - Intermediate System to Intermediate System Intro

 

There is much information about ISIS history and present state, when I want to study something new I am looking for the small bullets that make subject easier to understand, once I got the basics I am taking each point and digging into it, here I would like to give the key elements for understanding ISIS and I would have to say  from the start that every point can be elaborated into at least an article if not a book (exaggerating) by itself:

  • ISIS link state protocol (most important key to start with and easiest to remember)
  • ISO protocol working based on CLNP (Connection Less Network Protocol)
  • Support IP Routing
  • Router (Node or IS) Addressing use 8 – 20 byte hex format address ( AREA + SYS-ID + NSEL )
  • ISIS have 2 hierarchy called Level 1 and Level 2
  • IS can be either Level 1 or Level 2 or Level 1 + 2
  • Level 1 may only have neighbor relations within the same area and only with L1 or L1 + L2 IS
  • Level 2 may establish neighbors relation with other areas, Level 2 also refer to as backbone (some time compared to OSPF area 0)
  • In case level-1-2 is used and the neighbor IS is also level-1-2 and both systems are in the same area, the IS will form 2 neighbors 1 for Level 1 and another for Level 2.
  • DIS – Designated IS very similar to DR function in OSPF to reduce the size of the database and allowing efficient scalability, one exist in every broadcast domain and level
  • DIS is preemptive eligible meaning that is a IS will come up with stronger parameters it will take the DIS role
  • Only 2 types of interfaces, broadcast and point to point
  • Authentication can be done separately on Hello messages or link state updates
  • Support extensions using different TLV’s (Type length value) like Graceful restart, TE…

 

image

What you see from below is that R3 is the the DIS, according to the pseudonode see at the bottom of the output generated by the DIS LSP with metric 0 to each of the routers on the LAN.

 

R1#show isis database detail
IS-IS Level-1 Link State Database:
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime      ATT/P/OL
R1.00-00            * 0x00000006   0x1919        1114              0/0/0
  Area Address: 49.0001
  NLPID:        0xCC
  Hostname: R1
  IP Address:   10.123.0.1
  Metric: 10         IP 10.123.0.0 255.255.255.0
  Metric: 10         IS R3.01
R2.00-00              0x00000004   0x0CBF        1165              0/0/0
  Area Address: 49.0001
  NLPID:        0xCC
  Hostname: R2
  IP Address:   10.123.0.2
  Metric: 10         IP 10.123.0.0 255.255.255.0
  Metric: 10         IS R3.01
R3.00-00              0x00000004   0xFA68        960               0/0/0
  Area Address: 49.0001
  NLPID:        0xCC
  Hostname: R3
  IP Address:   10.123.0.3
  Metric: 10         IP 10.123.0.0 255.255.255.0
  Metric: 10         IS R3.01
R3.01-00              0x00000004   0x3195        1101              0/0/0
  Metric: 0          IS R3.00
  Metric: 0          IS R1.00
  Metric: 0          IS R2.00
IS-IS Level-2 Link State Database:
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime      ATT/P/OL
R1.00-00            * 0x00000007   0x0E23        1004              0/0/0
  Area Address: 49.0001
  NLPID:        0xCC
  Hostname: R1
  IP Address:   10.123.0.1
  Metric: 10         IS R3.01
  Metric: 10         IP 10.123.0.0 255.255.255.0
R2.00-00              0x00000003   0x05C7        354               0/0/0
  Area Address: 49.0001
  NLPID:        0xCC
  Hostname: R2
  IP Address:   10.123.0.2
  Metric: 10         IS R3.01
  Metric: 10         IP 10.123.0.0 255.255.255.0
R3.00-00              0x00000004   0xF171        1120              0/0/0
  Area Address: 49.0001
  NLPID:        0xCC
  Hostname: R3
  IP Address:   10.123.0.3
  Metric: 10         IS R3.01
  Metric: 10         IP 10.123.0.0 255.255.255.0
R3.01-00              0x00000004   0xE26C        1180              0/0/0
  Metric: 0          IS R3.00
  Metric: 0          IS R1.00
  Metric: 0          IS R2.00
R1#

 

Monday, July 11, 2011

Step by Step Into MPLS – VRF LITE

 

Although VRF (virtual routing and forwarding) is not actually part of the MPLS you can think of the VRF as a helper for the MPLS in achieving the MPLS VPN infrastructure, now as I would like to make that a very simple to understand guide , I will address here only the VRF part without any MPLS, also known as VRF Lite.

Simple Topology :

vrf_lite_basic

R1 Configuration R2 Configuration

!
ip cef
no ip domain lookup
!
!
ip vrf VRF_GOLD
!
ip vrf VRF_SILVER
!
!
interface FastEthernet0/0
no ip address
duplex auto
speed auto
!
interface FastEthernet0/0.1
encapsulation dot1Q 100
ip vrf forwarding VRF_SILVER
ip address 10.0.0.1 255.255.255.0
!
interface FastEthernet0/0.2
encapsulation dot1Q 200
ip vrf forwarding VRF_GOLD
ip address 20.0.0.1 255.255.255.0
!

!
ip cef
no ip domain lookup
!
ip vrf VRF_GOLD
!
ip vrf VRF_SILVER
!
!
interface FastEthernet0/0
no ip address
duplex auto
speed auto
!
interface FastEthernet0/0.1
encapsulation dot1Q 100
ip vrf forwarding VRF_SILVER
ip address 10.0.0.2 255.255.255.0
!
interface FastEthernet0/0.2
encapsulation dot1Q 200
ip vrf forwarding VRF_GOLD
ip address 20.0.0.2 255.255.255.0
!
!

 

As you can see from above I have done something very simple, 2 VRF’s GOLD and SILVER, I have configured sub interface for FastEthernet 0/0 and each is assigned to its own VRF with the ip vrf forwarding <VRF_NAME> command.

see what happen if I try to see my routing table:

R1#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route
Gateway of last resort is not set

What happen here?! where are my connected interfaces ?!

Well this is the VRF, as you can see from above configuration I have configured only interface assigned to VRF, and the VRF job is to take my router and give each VRF a totally separate virtual ip routing table. you can see the same result is with R2 main routing table.

R2#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route
Gateway of last resort is not set

So , where is the routing table I have created?!

R1

R1#sh ip route vrf VRF_GOLD
Routing Table: VRF_GOLD
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
     20.0.0.0/24 is subnetted, 1 subnets
C       20.0.0.0 is directly connected, FastEthernet0/0.2
R1#sh ip route vrf VRF_SILVER
Routing Table: VRF_SILVER
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
     10.0.0.0/24 is subnetted, 1 subnets
C       10.0.0.0 is directly connected, FastEthernet0/0.1

 

R2

R2#sh ip vrf
  Name                             Default RD          Interfaces
  VRF_GOLD                         <not set>           Fa0/0.2
  VRF_SILVER                       <not set>           Fa0/0.1
R2#sh ip route vrf VRF_GOLD
Routing Table: VRF_GOLD
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
     20.0.0.0/24 is subnetted, 1 subnets
C       20.0.0.0 is directly connected, FastEthernet0/0.2

 

Now lets check simple connectivity:

R2#ping 20.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 20.0.0.2, timeout is 2 seconds:
.....

 

Now what is going on?!  I am pinging my own interface!!!

Relax again, when working with VRF everything need to be referred with the VRF, ping traceroute…

R2#ping vrf VRF_GOLD 20.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 20.0.0.2, timeout is 2 seconds:
!!!!!
R2#ping vrf VRF_GOLD 20.0.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 20.0.0.1, timeout is 2 seconds:
.!!!!
R2#ping vrf VRF_SILVER 10.0.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds:
.!!!!

 

Now I would like to take it one step further and show you that the VRF is locally significant, meaning the router it self have virtual separation there is no tagging or added header’s or anything like MPLS.

R2(config)#ip vrf VRF_A
R2(config-vrf)#ip vrf VRF_B
R2(config-vrf)#int f0/0.1
R2(config-subif)#ip vrf f
R2(config-subif)#ip vrf forwarding VRF_A
% Interface FastEthernet0/0.1 IP address 10.0.0.2 removed due to enabling VRF VRF_A
R2(config-subif)#ip add 10.0.0.2 255.255.255.0
R2(config-subif)#int f0/0.2
R2(config-subif)#ip vrf forwarding VRF_B
% Interface FastEthernet0/0.2 IP address 20.0.0.2 removed due to enabling VRF VRF_B
R2(config-subif)#ip add 20.0.0.2 255.255.255.0
R2(config-subif)#^Z
R2#sh
*Mar  1 00:08:58.651: %SYS-5-CONFIG_I: Configured from console by console
R2#sh ip int b
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            unassigned      YES unset  up                    up  
FastEthernet0/0.1          10.0.0.2        YES manual up                    up  
FastEthernet0/0.2          20.0.0.2        YES manual up                    up  
R2#sh ip vrf
  Name                             Default RD          Interfaces
  VRF_A                            <not set>           Fa0/0.1
  VRF_B                            <not set>           Fa0/0.2
  VRF_GOLD                         <not set>
  VRF_SILVER                       <not set>

as you can see from above I have configured 2 new VRF’s and reassign them to the interfaces, replacing old VRF_GOLD and VRF_SILVER, notice I had to reconfigure the ip address, as when assigning VRF to an interface the ip address is removed (I have just assigned the same to each interface)

Now lets test

R2#ping vrf VRF_A 10.0.0.1 repeat 1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 200/200/200 ms

 

Success !!!

Now If you have any doubts

R1#debug ip packet detail
IP packet debugging is on (detailed)
R1#
*Mar  1 00:09:20.979: IP: tableid=1, s=10.0.0.2 (FastEthernet0/0.1), d=10.0.0.1 (FastEthernet0/0.1), routed via RIB
*Mar  1 00:09:20.979: IP: s=10.0.0.2 (FastEthernet0/0.1), d=10.0.0.1 (FastEthernet0/0.1), len 100, rcvd 3
*Mar  1 00:09:20.983:     ICMP type=8, code=0
*Mar  1 00:09:20.983: IP: tableid=1, s=10.0.0.1 (local), d=10.0.0.2 (FastEthernet0/0.1), routed via FIB
*Mar  1 00:09:20.983: IP: s=10.0.0.1 (local), d=10.0.0.2 (FastEthernet0/0.1), len 100, sending
*Mar  1 00:09:20.983:     ICMP type=0, code=0
R1#un all

 

Now I could have made it more confusing and switch the names, but why go there take below .net file for GNS and play your self:

autostart = False
[127.0.0.1:7200]
    workingdir = D:\DYN\Work
    udp = 10000
    [[3640]]
        image = D:\DYN\C3640-JK.BIN
        idlepc = 0x6060d328
        ghostios = True
        chassis = 3640
    [[ROUTER R1]]
        model = 3640
        console = 2000
        cnfg = R1.cfg
        slot0 = NM-1FE-TX
        f0/0 = R2 f0/0
        x = -221.0
        y = -91.0
    [[ROUTER R2]]
        model = 3640
        console = 2001
        cnfg = R2.cfg
        slot0 = NM-1FE-TX
        f0/0 = R1 f0/0
        x = 144.0
        y = -83.0
[GNS3-DATA]
    configs = .
    [[NOTE 1]]
        text = f0/0
        x = -6.99933176856
        y = 21.7687899898
        interface = R2 f0/0
    [[NOTE 2]]
        text = f0/0
        x = 72.9993317686
        y = 22.2312100102
        interface = R1 f0/0

 

This is the very basic VRF , If you understand that it is the first step to understanding MPLS VPN’s

Thursday, February 25, 2010

TCP Over Satellite communications

First I would like to say it has been a very long time since my last article, but now I am in the mode for writing so I would like to share my expireance with TCP and Satellite Communication challanges. I am working at Expand Networks and one of our advantages is in optimizing TCP communication in challanging enviorments such as Satellite, so what is so challanging you ask??
  • The Satellites we use for communication are up in the sky ~35000 kilometer away from ground also called GEO Sat
  • Communication between ground station to the Satellite easly impacted from enviorment (clouds, rain, snow, solar events...)
  • Satellite is a shared resource

All the Satellite set a big challange in TCP communication, one of the main is RTT (round trip time), the other is packet loss due to channel error's the satellite may encounter.

To overcome this challanges we use some of the avilable TCP enhancments avilable such as: proxying the TCP session and in the session over the satelite increasing Window Size using the window scale options. additional to that selecting the congestion control that is most suitable for the enviorment we are in. the congestion control as his name indicate is an algorithem that tells the TCP when to back off because a congestion was detected or when to continue and at what level to send the tcp traffic.

Here are Some of the Congestion Control Algorithems:

Reno - the most common used today by default (linux implement NewReno), basicly during the slow start increasing 1/cwnd for each ACK recived and decrease by 0.5 if a loss was detected

BIC - binary increase congestion as the name imply it uses some binary search algorithem to esitimate the correct cwnd

CUBIC - another algorithem considered some kind of enhancment to the BIC algorithem

Hybla - some kind of a hot topic in congestion control algorithem over satellite communication

Vegas, illinois,Veno, Westwood....

basicly you can see that there are many algorithms out there and all are created due to diffrent challanges sattelite , wireless or even wired communication had brought over the years.

There is no ultimate algorithem that can handle all sitiuations (as of today), each have his advantages and disadvantages, Reno is ok when delay is going +-20ms + RTT but more then that if you had +-100ms + RTT with Reno you would be in a problem as it would often back off the window by half.

Sunday, March 01, 2009

TCP Window Scale

One of the overlooked subjects especially when it come to the CCIE RS is the real deep knowledge and understanding of TCP, the one subject from the scope of TCP that I would like to pass to you readers is the concept of Window Scaling. Why do we need window scaling or what the hell is it?! First may be lets start with the why, I do not know about you guys but when I am buying something I expect to utilize it fully and not half way, and the same goes to my Internet line if I buy 10Mbps pipe I do not want to utilize only 5Mbps. So What is Window Scaling and how can he help us better utilize our pipe?! Window Scaling is an optional enhancement that allows us to extend our window size so you say wait why do I need to extend my window size? Well normally the window size is 16 bit with a max size of 64K byte and when you are talking about a in your LAN delay (1ms avg) that is more then enough for just above 500Mbps but when we are over the WAN we start experiencing some delays the amount of throughput we can provide is decreasing fast, already with 10ms delay you can have only just above 5oMbps with 100ms we already in 5Mpbs and you see where is that going. so what and how we can take the 16bit we have in the TCP header and make them bigger well the simple answer is we cant as we have only 16bit not one bit more in the header for window. but what we can do is use the options 3 byte filed to where we indicate what is our scale factor, the defined scale factor can be between 0 to 14 where the max window can be 1GB 65536 * (2^14) = 1073741824 well now we are talking this is a window. but with grate window come grate responsibility, now we need to watch out for overflowing the network causing congestion (the congestion will be for another talk). So basically what we learned is that the higher the Delay we need a bigger window to free the belt on our traffic. The Max Throughput calc is actually very simple: [ WIN(in bits)/delay(in second) ] / 1000000 = Throughput in Mbps Scale Window calc is: (2^scale factore) * window(bytes) Notice that as the WS is optional it must be offered by both sides to and the lowest WS factor win.