hi I'm Jason ROM with dev central

welcome to this episode of light board

lessons and today we're going to talk

about the basics of I rule anatomy so

we'll get this on the board and then you

know before we get into the specifics of

eye rules I want to talk about kind of

the different languages and where where

I drool sits and so if we have kind of a

line of what's easy for humans easy for

people and hard for computers I'm just

going to put PCs and then what's easy

for PCs but hard for people we have

interpreted languages that sit here and

those are pretty easy for people a

Python write Python Perl tickle those

are interpreted languages they're pretty

easy for for people to understand very

hard for computers to understand and

then kind of in the middle you have

compiled languages and that's like C C++

you know Java those are compiled

languages and then of course you have

machine languages like assembly and if

anybody's had an assembly class I'm

sorry I had one in come to his brew but

you know that's that's basically you're

at the zeros and the ones and and in

punch cards way back in the day you know

very easy for for computers because

that's kind of really really close to

their native language but that's very

hard for people and so where I rules

exists on this spectrum is you would

think tickle its interpreted I rules

would be here but our rules actually

kind of live right here in between

compiled and interpreted languages and

that's because I

fools once they're saved they're

compiled to bytecode and not only is

tickle a very lightweight language but

compiling it down to bytecode makes it

very very fast and the reason it needs

to be very very fast is if you if you

look at like analyzing a firewall log or

converting a configuration or or parsing

text on a server that doesn't have to

happen quickly there's no there's no

immediacy to that however if you have

hundreds of thousands of connections per

second coming through your box and then

you have to fire up a runtime

interpreter for every single connection

that comes through that's obviously

going to slow your box down like crazy

and so so that's why everything's

compounded a bi code makes it very very

fast very very light and and so that's

where I rules lives in that spectrum so

where I rules are like tickle are things

like variables you know variables

commands you know comments a lot of the

conditionals so conditionals like you

know if else switch those kinds of

things from tickle the comments you know

they all start with the bang of you know

commands like put straying down and I

rules we don't have put string we use

the log but uh you know string commands

you know the ones that work in tickle

they work in IEEE rules variables we

have extended that but you know regular

local variables work just fine in IEEE

rules like they do in tickle so these

are ways that I rules are like tickle

the ways that they're not alike is this

concept of events and basically if you

look at the way the the big IP works is

we have a connection we have a client

and that client is going to come down

into a big IP this client connection

and then that's going to get passed on

to a server while it's being processed

here the TMM the traffic management

microkernel is going to inspect that

traffic based upon a certain level of

filters and those filters are realized

for your connection based on the

profiles that you have applied to your

connection and so if I don't have

anything applied and I'm just going to

send it through the IP is still going to

do some protocol validation to make sure

everything's legit you know with like

DDoS stuff that's in hardware or in

software it's still going to do some

checking in some protocol validation but

not to the level as it will if you apply

profiles and so if you apply a TCP

profile now there's going to be certain

attributes about TCP available to you to

do something with and the same is true

if you apply an HTTP profile now in the

context of I rules if you don't have HDD

profile applied you can still get to

that data if you have TCP applied

because then you can do you can collect

all that TCP payload and then you can

buy RFC's field offsets you can do a

binary scan and pull all that data out

now we have an HD profile that will make

it so that you don't have to do that but

but you use an HTTP profile to get at

HTTP data so things like headers and

cookies and and methods and and all of

the HTTP protocol fields then you can

get access to if you apply the HDD

profile and then of course if you have

an SSL profile applied now the SSL type

events are available and so when you

look at an I rule this the syntax of the

code is when when starts an event and so

you'll have any number of events now

when you have TCP HTTP and SSL profiles

attached to your virtual server that

gives you access to

HTTP requests in response events it

gives you access to client s SL

handshake events it gives you access to

TCP data and the client accepted event

and so you'll fill in an event here

let's just let's do client accepted and

then the bracket here and here denotes

the event so the client accepted happens

when a TCP handshake happens so once

that happens the TMM will fire this

event and then you can do any number of

things in here if you want to log the

source IP if you want to extract

something from TCP payload you can do

all of that in here if you want to log

events that happens in the context of

this event then within an IEEE rule you

can have more events as more events fire

and so we could say because we have HTTP

profile we can do when HTTP requests and

then within the get request so if you're

on the wire you're in your browser you

go to espn.com or even better you come

to the central f5 comm to watch this

video there's going to be a get and then

you know whatever the URL is so let's

say video and so when this comes in on

the wire and the client handshake has

already happened the next request in

this get slash video that's when this

HTTP request event fires and then of

course you can do anything on the

request side that you might do you might

say I don't want you to go to slash

video anymore and you redirect them or

on the application server you've made

some changes and slash video isn't there

anymore but you don't want to deal with

any client-side rewrites at this time so

then you'll just rewrite that to send it

somewhere on the back side and so you

know these are on the client side of the

connection that's all living here

there are also events that happen on the

server side and those are like a you

know server connected HDTV response and

so you can change all of that data based

upon events so there is so much more

that we could talk about we could go on

for hours on every single one of these

types of commands comments conditionals

variables we could go even more in-depth

on events but I think I've gone on long

enough and so we'll wrap this video

we'll do more I rules videos in the

future hopefully this has been helpful

and we look forward to hearing from you

on what kind of content that you would

like to see in these life board lessons

and we'll see out there in the community