Understanding OSPF Type-4 LSA

Understanding OSPF Type-4 LSA

The OSPF Type-4 LSA is perhaps most misunderstood subject with honors to OSPF for folks that are just or halfway learning the protocol. I was going through one of the blog which explain the same OSPF Type-4 LSA & in comments one of the individual asked that “How ABR will come to know that when to generate Type-4 LSA ?”

Interesting question & then I decided to illuminate more on this & also we will take a look at OSPF Type-4 LSA.

 Below is our topology that we will be using for demonstration:-  

We will check the following concept in OSPF:-

•   Who will generate Type-4 LSA ABR or ASBR?
•   When & Why ABR Generate Type-4 LSA or How ABR will come to know about ASBR   presence?

Let’s see what is Type-4 LSA?

“Type-4 LSA - This is the ASBR Summary LSA this basically identifies the ASBR of a specific area (note that inside the area where the ASBR is this LSA will not exist, instead the type-1 LSA will be used in order to announce the ASBR of the area). Who is the ASBR of the area? The type-4 LSA is there in order to answer this question, so this is injected by the ABR in order to announce the presence of the ASBR in a particular area.”

The above statement is very clear & gives all answer that we’re looking for, one of the perfect statement for OSPF type-4 LSA.

Below statement from RFC 2328:-

12.1.5. Advertising Router

       This field specifies the OSPF Router ID of the LSA's

       originator.  For router-LSAs, this field is identical to the

       Link State ID field.  Network-LSAs are originated by the

       network's Designated Router.  Summary-LSAs originated by

       area border routers.  AS-external-LSAs are originated by AS

       boundary routers.

RFC 2328 clearly state that the Summary LSA is generated by ABR (Area Border Router), so now question comes here that when ABR will generate Type-4 LSA or How ABR will know the presence of ASBR?

Let’s LAB it and find out the answers:-

R2 output: -

Here we can see that R2 is configured with Area 10 & R2 see R1 as ABR.

R3 Output: 

Here we can see that R3 is configured with Area 0 & R3 see R1 as ABR, Also we had configured EIGRP between R3 & R4 but redistribution has not configured.

R1 Output:-

 

What we can see here:

• Src : 192.168.1.1 & Dest : 224.0.0.5
• Source OSPF Router ID : 1.1.1.1
• Area ID : 10
• LS Type : Summary LSA
• Link state advertisement type : Summary LSA ASBR (4)
• Link State ID : 3.3.3.3 (This is ASBR router ID which was advertised by ABR in Type 4 LSA)
• Advertising Router : 1.1.1.1  ( R1 is advertising R3 Router ID  as ASBR)

So here you can see that Type-4 LSA is generated by ABR, Now next question is How ABR come to know that R3 is ASBR? Is there any LSA get exchanged between ABR & ASBR? Let’s find out …

Packet capture between R1 & R3: -

What we can see here:

• Src : 192.168.2.3 & Dst : 224.0.0.5 ( Type-1 LSA was generated by R3 towards R1)
• Flags : E – AS boundary Router  ( Here you get your answer : R3 generate Type-1 LSA with E-bit towards R1 stating that “I am AS boundary router” )

So let's what we got : 

When we redistribute any routing protocol in OSPF domain then that router will generate Type-1 LSA and inform all routers within an area that “I am AS boundary Router” with Flag - E bit on  . So the ABR will come to know that we have ASBR & then ABR will generate Type-4 LSA towards other areas which are connected to ABR. 

BIG IP F5 LTM Tutorial - Part 10

6. Profiles

Ø  Profile is very powerful configuration tools in BIG IP F5 LTM which hold all traffic management & simplify settings of objects which can be tedious & complicated without these profiles.

Ø  Profiles  Provide :

o   A single place to define specific traffic behaviour.

o   A centralized place to utilize that object settings.

o   A Centralized place to change any settings & have them applied to all application using an existing profile.

Ø  A profile tells a virtual server how to process packets when it receives based upon the profile’s configuration parameters

.

Ø   Profiles are used by LTM system to manage the processing of traffic through each virtual server.

For Example:

o   If you want to encrypt /decrypt traffic then you can use clientssl/serverssl profile.

o   If you want to increase the speed at which the virtual server processes HTTP requests then assign fasthttp profile.

Ø  You can use existing profile or can create custom profile based on application requirement.

Ø  You can associate multiple profiles to single virtual server.

Ø  We have certain restriction & dependency using these profiles i.e.

o   HTTP profile needs TCP profile in place to process traffic.

o   HTTP & FTP profile cannot associate with single virtual server.

Ø  As a general rule, profile of given layer of OSI model are depend upon profile of lower layers & profile of the same layer cannot co-exists.

o   For Example: HTTP profile is required to process cookies and HTTP profile requires a TCP profile.

o   For Example: TCP & UDP profile cannot co-exist in one Virtual Server.

Ø  At a minimum, a Virtual Server must reference a connection lever profile, based on UDP, FastL4 or TCP profile type. Thus if you have not assigned any profile then LTM adds a default profile (UDP, FastL4, TCP) depend  on Virtual Server protocol setting , If you have selected UDP then it will add UDP profile or if you have selected TCP then it will add FastL4 Profile. ( Types of profile are mention below)

Ø  Types of profile :

o   Protocol (Connection Oriented)

ü  Protocol Support parameters concerning timeouts and connection management. All Virtual Server have at least one protocol profile.

o   Services (Data Type Oriented)  

ü  Service based profile support special feature for select application. For HTTP it’s knowledge of various HTTP headers & data structure. For FTP it’s the ability to support Active / Passive FTP, but both services will have same protocol profile i.e. TCP.

o   Persistence (Session Oriented)

ü  Persistence profile defines multiple methods that the LTM system uses to treat multiple TCP connection to treat TCP connections as Single session. There are different type of persistence profile & you can configured based or your requirement.

o   SSL (Encryption Oriented)

ü  SSL based profile support encryption / decryption.

o   Authentication (Security Oriented)

Ø  Configuration of Profile :

o   Till now we had configured Node, Pool Member, and Pool & Virtual Server.

o   After configuration you can verity that by default Virtual Server will have FastL4 profile.

o   You can modify these profiles or can create custom profile.

o   For MY_SERVER_HTTP - fasthttp  and MY_SERVER_HTTPS- clientssl

root@chetan(Active)(tmos)# modify ltm virtual MY_SERVER_HTTP profiles replace-all-with { fasthttp }

root@chetan(Active)(tmos)# modify ltm virtual MY_SERVER_HTTPS profiles replace-all-with { clientssl }

o   Default available profile options under Virtual Server  : - 

o   Also you can create custom profile based on application requirement.

Note: Check restriction before applying any profile to virtual server. 

BIG IP F5 LTM Tutorial - Part 9

Now we are ready to Configure BIG IP F5 LTM through CLI mode and after this post every one will know that in reality configuring through CLI is VERY EASY.

CLI Configuration of Nodes, Pool Member, Pools, Virtual Server & Monitors

Ø  Telnet / SSH to BIG IP Box

Ø  After success full login you will get prompt : [root@chetan:Active] config #

Ø  This prompt or CLI mode is the legacy CLI mode but we are not going to use this CLI mode.

Ø  We will be working with shell mode, for shell mode type “tmsh” and hit enter. You will go to BIG IP shell mode & will get prompt root@chetan(Active)(tmos)# . ( TMOS that we discussed Part2 ) 

Note : To auto complete your command you can use "Tab" button. It will help you to complete the command & '?" is to check the available options. ( Same as Cisco )

Configure Node & assign ICMP monitor:-

 root@chetan(Active)(tmos)# create ltm node 172.16.1.2 up

root@chetan(Active)(tmos)# modify ltm node 172.16.1.2 monitor icmp

root@chetan(Active)(tmos)# modify ltm node 172.16.1.2 screen TEST_SER1

root@chetan(Active)(tmos)# create ltm node 172.16.1.1 up

root@chetan(Active)(tmos)# modify ltm node 172.16.1.1 monitor icmp

root@chetan(Active)(tmos)# modify ltm node 172.16.1.1 screen TEST_SER2

root@chetan(Active)(tmos)# show ltm node  172.16.1.1

root@chetan(Active)(tmos)# show ltm node  172.16.1.2

Configure Pool, Adding Members from Node list; Assign Monitors & Load balancing method

Ø  Assign Custom Monitors

root@chetan(Active)(tmos)# create ltm pool MY_SER1 members add { 172.16.1.1:80 }

root@chetan(Active)(tmos)# create ltm monitor http TEST_HTTP send GET/index.html interval 10 timeout 30

root@chetan(Active)(tmos)# modify ltm pool MY_SER1  monitor TEST_HTTP

root@chetan(Active)(tmos)# modify ltm pool MY_SER1  load-balancing-mode round-robin

Ø  Assign Default Monitors

root@chetan(Active)(tmos)# create ltm pool MY_SER2 members add { 172.16.1.2:443 }

root@chetan(Active)(tmos)# modify ltm pool MY_SER2 monitor https_443

root@chetan(Active)(tmos)# modify ltm pool MY_SER2  load-balancing-mode round-robin

Ø  Verification Command

root@chetan(Active)(tmos)# show ltm pool MY_SER1

root@chetan(Active)(tmos)# show ltm pool MY_SER2

root@chetan(Active)(tmos)# show ltm pool MY_SER1  members

root@chetan(Active)(tmos)# show ltm pool MY_SER2  members

Configure Virtual Server and Assign Pool

root@chetan(Active)(tmos)# create ltm virtual MY_SERVER_HTTP destination 1.1.1.1:80

root@chetan(Active)(tmos)# modify ltm virtual MY_SERVER_HTTP  pool MY_SER1

root@chetan(Active)(tmos)# show ltm virtual MY_SERVER_HTTP

root@chetan(Active)(tmos)# create ltm virtual MY_SERVER_HTTPS destination 2.2.2.2:443

root@chetan(Active)(tmos)# modify ltm virtual MY_SERVER_HTTPS  pool MY_SER2

root@chetan(Active)(tmos)# show ltm virtual MY_SERVER_HTTPS

To Delete Config

root@chetan(Active)(tmos)# delete  ltm virtual MY_SERVER

Note : If you remember we discussed the CLI hierarchy in Part6, if you won't remember then  please check & come back, so that you can easily understand the Command line interface. It will explain you that why & when to use ltm , sys, net ...etc.

Show Command:

root@chetan(Active)(tmos)# show sys hardware

root@chetan(Active)(tmos)# show sys license

root@chetan(Active)(tmos)# show sys version

root@chetan(Active)(tmos)# show sys cpu

root@chetan(Active)(tmos)# sh net route

root@chetan(Active)(tmos)# sh net arp

root@chetan(Active)(tmos)# sh net interface

root@chetan(Active)(tmos)# sh net vlan

root@chetan(Active)(tmos)# show ltm virtual MY_SERVER

root@chetan(Active)(tmos)# show ltm pool MY_POOL members

root@chetan(Active)(tmos)# show ltm node  172.16.1.1

root@chetan(Active)(tmos)# show ltm virtual-address

root@chetan(Active)(tmos)# sh running-config net interface

root@chetan(Active)(tmos)# sh running-config net vlan

root@chetan(Active)(tmos)# sh running-config net route

root@chetan(Active)(tmos)# sh running-config net self

root@chetan(Active)(tmos)# sh running-config ltm virtual

root@chetan(Active)(tmos)# sh running-config ltm pool

root@chetan(Active)(tmos)# sh running-config ltm pool members

root@chetan(Active)(tmos)# sh running-config ltm node

root@chetan(Active)(tmos)# sh running-config ltm virtual-address all-properties

[root@chetan:Active] config # bigtop –n (real time statistics)

Type of Load balancing:  Static & Dynamic

Static Load balancing              : Ratio & Round Robin

Dynamic Load Balancing        : Least Connection, Fastest, Observed, Predictive, Dynamic Ratio

dynamic-ratio-member	observed-node
dynamic-ratio-node	predictive-member
fastest-app-response	predictive-node
fastest-node	ratio-member
least-connections-member	ratio-node
least-connections-node	round-robin
least-sessions	weighted-least-connections-member
observed-member	weighted-least-connections-node

Advance Configuration:

root@chetan(Active)(tmos)# modify ltm node 172.16.1.1 ratio 10

ü  Specifies the fixed ratio value used for a node during ratio-node load balancing.

root@chetan(Active)(tmos)# modify ltm pool MY_SER1 members modify { all { priority-group 10 } 172.16.1.1:http }

ü  Specifies the priority group within the pool for this pool member. The priority group number specifies that traffic is directed to that member before being directed to a member of a lower priority. The default value is 1. This feature is use when you need logical grouping in your pool & treat them as a primary server & secondary server. The Traffic will be forwarded to primary or higher priority group server unless those servers fail or reach their fail threshold.  (Priority group is by default disabled )

root@chetan(Active)(tmos)# modify ltm pool MY_SER1  members modify { all { connection-limit 1000 } }

ü  Specifies the maximum number of concurrent connections allowed for a pool member. The default value is 0 (zero)

root@chetan(Active)(tmos)# modify ltm pool MY_SER1  members modify { all { dynamic-ratio 10 } }

ü  Specifies a range of numbers that you want the system to use in conjunction with the ratio load balancing method. The default value is 1

root@chetan(Active)(tmos)# modify ltm pool MY_SER1 members modify { all { state down }}

ü  Marks the pool member up or down. The default value is up

root@chetan(Active)(tmos)# modify ltm pool MY_SER1 min-active-members (value)

ü  Specifies the minimum number of pool members that must be up; otherwise the system takes the action specified in the min-up-members-action option. Use this option for gateway pools in a redundant system where a unit number is applied to the pool. This indicates that the pool is only configured on the specified unit.

Note: All advance option is not covered here & for further detail please visit www.f5.com

BIG IP F5 LTM Tutorial - Part 8

5. Monitors

Overview:

Health monitor test the availability of devices and services on the network and are used to determine whether pool member are working properly, Monitor test the availability of member based on criteria defined by administrator. Usually we test the availability of network devices using ICMP protocol but we cannot verify accessibility of application using ICMP protocol. So to resolve this issue we can use application based monitor like we can monitor HTTP, TCP or any port that is used by particular application or we can send request to that particular port to get expected response. So in this way we can monitor the availability of applications and also we can assign multiple monitors to node, member or pool to verify availability of applications.

BIG IP LTM offer different types of monitor:

Ø  Node/ Address Checking

o        Some monitor is primarily designed to determine whether an IP address is reachable. When a monitor associated with a node is unsuccessful then that node will be marked as an OFFLINE.Usually these types of monitors will use ICMP to determine availability of node.

Ø  Service Checking

o      This is another type of monitor determine whether a service is available by opening connection with IP address and port. The TCP monitor is an example of this type of check.These monitor will report UP when TCP connection is establish with particular IP and port then it will close the connection & if TCP connection is not establish then it will report OFFLINE.

Ø  Content Checking

o       Some monitor do more than service verification, like they also test whether the server is serving appropriate content which make sense, for example if you have setup HTTP server and you assign monitor which will test HTTP port but might be there could be error with HTTP content so service checking monitor cannot identity these error. So content checking monitors will help you to verify the appropriate response from particular server.The monitor will establish TCP connection & then issue a command to check the response from server. i.e. for HTTP  it will issues GET / command .

Ø  Integrative Checking

o       These are advance type of monitor which help you to determine availability of server using multiple content checking .Monitors can also interact with server, sending multiple commands and will processing multiple responses.

Ø  Virtual Server , Pool ,Member & Node Status :

•  BIG IP F5 will forward traffic to virtual server when it is marked as unknown. Unknown status means  either you have not assigned any monitor or BIG IP F5 has not received reply to that monitor status.

Ø  Green Status :

o   General          : Monitor is successful.

o   Node             : The Most recent monitor was successful.

o   Pool Member : The Most recent monitor was successful.

o   Pool               : At least one pool member is available.

o   Virtual Server : At least one pool member is available.  

Ø  Unknown Status :

o   General          : No monitor was assigned or the monitor timeout has not been reached.

o   Node             : Monitor has not assigned.

o   Pool Member : Monitor has not assigned.

o   Pool               : All members are unknown.

o   Virtual Server : All pools are unknown.

Ø  Offline Status :

o   General          : Monitor has failed.

o   Node             : Monitor did not succeed during the recent check.

o   Pool Member : Monitor did not succeed during the recent check.

o   Pool               : One or More members are failed during the recent check & showing offline                                                                                            

o  Virtual server  :  One or More pools are offline & no pool members are available.

Till now we had completed:

• Overview of Load Balancers 
• Basic Config of BIG IP LTM : Licensing, Vlan , IP address assigning ..etc  
• BIG IP CLI Utility : bigpipe, tmsh.. etc
• Load Balancers Terminology : Node, Pool Members, Pools & Virtual Server.
• Monitors :  Types of monitors & etc... 

So now we are ready to configure all those thing that we learned & In my next post we will do only configuration & verification.

BIG IP F5 LTM Tutorial - Part 7

4. Load Balancing Terminology

Ø  Nodes  

• The devices represented by the IP address of Pool Member are called Nodes. Hence Node has only IP address & may represent in many pool members. ( IP Address )

Ø  Pool Members 

• A pool member is an IP address and service port combination that is hosted by physical server.
• A single server can host any number of pool member because the different service ports may run various services. ( IP Address:Port )

Ø   Pools   

•  A pool is a group of pool member and is identified by name. In addition to pools member, pools also have their own load balancing method, monitors and other feature.

Ø  Virtual Servers

•   A virtual Server is a combination of Virtual IP address & service Port
• Virtual Server is mapped with multiple actual server or pools.  
• Virtual Server will perform multiple functions like: Server availability Load Balancing, translation of virtual IP address to actual IP address, Translate virtual server service ports to actual server service ports.
• By default translation of address & ports are enabled in virtual server.

Ø  Packet Flow through BIG IP :

ü  Client initiate request to BIG IP Virtual Server IP address & Service Port

ü  BIP IP translate VIP to actual IP address

ü  Server will see Client IP address as a source & own IP address in destination

ü  Server will reply to that session & BIG IP will translate back server actual IP to VIP address

BIG IP F5 LTM Tutorial - Part 6

3. BIG IP CLI Utility                     

Ø  BIG IP F5 Command Line Utility & Tools :-

•  Bigpipe Shell Utility  : Type “Bigpipe shell”  & hit enter for this utility {Prompt : bp>}
•  Config utility             : Type “config” {Initial Config Tool}
•  Bigtop utility             : Type “bigtop” {Display real time traffic}
•  Bigstart utility           : Type “bigstart” {Start, Stop, Restart various daemons}
•  TCL                        : iRules {Tool Command Language}
• Shell CLI Mode       : Type “tmsh” {Traffic Management Shell – Prompt  (tmos)# }

Ø  The BIG-IP system includes a tool known as the Traffic Management Shell (tmsh) that you can use to configure and manage the system from the command line.

Ø  “tmsh” is an interactive shell that you can use to manage the BIG-IP system. The structure of tmsh is hierarchical and modular as shown below. The highest level is the root module, which contains six subordinate modules: auth, cli, gtm, ltm, net, and sys.

Ø  Important things to remember when examining commands in TMSH:

• “Show” (usually) provides just the statistical information, with configuration parameters present to provide a level of disambiguation.
•  “List” provides actual configuration information, but just variations from the default. For example, “list /ltm virtual TEST will show you the configuration.
• “all-properties” extends a “list” command to show every configuration option, not just the variations from default.
• “Help” command is very useful if you are not familiar with CLI mode of TMSH. To use “HELP” command just uses the same structure mention above. For Example: “help ltm pool” this will show you all detail CLI syntax, description, configuration example & related options with their descriptions.
• “Save” command is used to save the running configuration.
• “Delete” command is used to delete the configuration

As per BIG IP F5:

    

“Show”                 :  View runtime information, statistics and status

“List”                     :  View configuration and settings

When I tested above command & there output then I found that “List” & “Show” command will give you almost identical output, so you can use both command which ever you want & found easy to use.

Note: Bigpipe Mapping with tmsh command: https://devcentral.f5.com/wiki/tmsh.BigpipeMappings.ashx