cisco image validations ( md5 )

At some given time, you will most likely upgrade a cisco  device ( router, switch, firewall,etc...)

With our cisco routers and switches, we have the ability to compute the hash value to ensure the image was not corrupt during the download from the cisco website,  and the ultimate uploading to our device.  I'm going to demonstrate  how we can check the image files.


1st

You will meed the CCO on-line or some other authoritative sources for the computed  hash known as a md5 CheckSum.

e.g ( cisco support page for a c3550 switch image that we will use  in this demo  )

In this example we upgraded a 3550-24port PoE switch earlier, and will now validate the image as it sits in the flash; " by comparing the md5 checksums to our CCO page".

Here's the switch;

 

Here's the internal flash contents;

 The file we will verify, is the iosimage file named c3550-ipservicesk9-mz.122-44.SE6.bin

The cli cmd for this activity  "verify"   will be used for the md5 checksum comparisons. We will use the /md5 option for computing the md5 checksum.

The last line, provides the  computed checksum value that should match the CCO  software download checksum. In this case, it does.

So we know the following;

• The image was not corrupt
• or tamper with 

We could also validated the image on most unix systems by using either cli cmd  "md5" or "md5sum", depending on OS type.

 

Notice how the computed values equals our CCO download page values?

Ken Felix

Freelance Network / Security Engineer

kfelix  ----a---t---socpuppets ---d---o---t---com

     ^      ^

=(  @   @ )=

          o

        /     \

BGP next-hop self

If you read my earlier post,  about the  bgp path-attributes  MEDs & NEXT_HOP, and remember that 3 router topology? Will I re-used that  topology for this blog and for further training.

The iBGP peers expects other iBGP peers to known the next-hop address,  or have reachability to the next-hop. These bgp iBGP peers do NOT modify the BGP next-hop information. So let's do some changes to my original design, and hopefully you will learn 2 unique behavior with BGP.

Here's the new topology;

R1 = AS1

R2 = AS2

R3 = AS2

Okay R1 config stays the same for this demo & training session ;

R1:

But on R2,  we made some changes,  1> we remove the neighbor 2.2.2.2 remote-as 3 and  2> converted her to AS#2;

And R3 is also now in  AS#2

Okay good so far ?

Well let's see, 1st let's look at the  R2  bgp table to ensure we still see 10.10.10.0/24 from  R1 ( AS#1 ).

Okay nothing changed. It looks good. Well let's see what  R3  who's now in AS#2 and what does he see.

Okay you should  see 2 things & I highlighted one of them.

1st the bigger issue;  <1.1.1.1>  is inaccessible due to the next_hop path_attribute was not changed by 2.2.2.1 ( R2 with in AS#2 )

2nd, we find the mertric value offered via R1 ( 1.1.1.1 ) is now  included for 10.10.10.0/24 on R3. Yes the metric stayed within the AS#2. So any iBGP peers would learn the same metric as the direct attached  R2 router.

Okay so how do we get past this inaccessible issue? 

Easy I will show you the rookie method,  if they would even noticed it. They typically would install a  static route point to  R2 on R3 route table.

Okay that fixed the problem or at least removed the inaccessible warning. But that's not the right recommended way or means or is it? We could also redistribute the  1.1.1.0/32 network from r2 perspective into AS2. And most service-provider does that in some cases.

But, you have one more  option; the execution of  next-hop-self  on the iBGP peer that learns the eBGP paths.

Okay we are going to do  the following & demonstrate this behavior;

1: first we  remove the static route that a rookie would install on R3

2:  and on R2 we will set the iBGP neighbor with the next-hop-self

3: we will clear the  iBGP relationship and re-monitor the bgp table on R3

on R2

and  on  R3

Notice the next-hop information is now  populated with 2.2.2.1 address ( R2 )  vrs the original  1.1.1.1 address ( R1 ). Cool, we have reachability  via iBGP to this route advertised via R1. And R3 has no knowledge in this case of the R1 bgp speaker. It's only BGP relationship is known and established with R2 via it's iBGP session.

Key take aways;

• metrics stay within the AS that learns it, but is not delivered outside of that AS

• be cautious of how BGP next-hop reachability  works &  with your iBGP peers

• iBGP peer that learns a eBGP path  do NOT by default ,  re-adjust the path_attribute  NEXT_HOP

Ken Felix

Freelance Network / Security Engineer

kfelix  ----a----t----socpuppets ---d---o---t---com

   ^      ^

=( *    * )=

        @

      /     \

Non-transitive Path Attributes BGP

A lot of confusion exists on  the BGP Path-Attribute  known as  MEDs. And one of the main issues that one needs to be aware of is ; " that this metric is non transitive"

What that means, a provider router does not send this the path_attribute outside of it's AS. Take this  simple BGP  topology

R1 = AS1

R2 = AS2

R3 = AS3

R1 is announcing the prefix 10.10.10.0/24 & sourced from it's  loopback interface,  with a metric value of 200.

"What would  R2 see ?"  and  "What would R3 see ?"


Okay let's see the cfg of the 3 players;


1st

R1:

R2:

R3:

Okay now let's look at the bgp table for 10.10.10.0/24;


1st

 R1;

I want to point out the following; the R1 is the source of the advertisement and the metric are only adjusted via the route-map applied on towards neighbor 1.1.1.2.


Now let's look at R2  bgp table;

Notice the metric it received from 1.1.1.1 ( R1 @ AS1 )   equals  200 ? Okay that's was because of the  applied  route-map called  bgp-med ; and with the  set metric 200  statement.


Now moving on to R3.

It's bgp table will not reflect this same metric as seen via R2. And that's the point of this blog and the title "Non-transitive attributes"

You notice we are metric free on R3 for advertisement received from  2.2.2.1 ( R2  @ AS2 ) for the  prefix 10.10.10.0/24.  R2 drop that attribute, &  from it's advertisements towards R3.



I hope this give you an ideal and better understanding on path attributes and how some things are not included in bgp announcements.


Here's some of the common  path_attributes that  you might run across ;

ORIGIN ( mandatory well known      how the route was originated  network statement, redistribute, etc.... )
AS_PATH  ( mandatory well known  changes each time we cross a AS boundary known simple as bgp path or AS hops towards the origination, as we cross AS, we add the AS# to this path_attribute  )
AS4_PATH  ( mandatory well known  4 byte AS same concept as the above )
NEXT_HOP  ( mandatory well known changes,  per each AS router  )

ATOMIC_AGGREGATOR ( discretionary well-known   provides information that part of the attribute might be lost during summarizations )
Local-Preference ( discretionary well-known   local within that AS locally )

AGGREGATOR  (optional transitive )
AS4_AGGREGATOR  (optional transitive )
COMMUNITIES  (optional transitive     used to enforce bgp policies , 32bit value  )
EXTEND_COMMUNITIES  (optional transitive     used to enforce bgp policies , extended and increase bit size  typically represented as AS:VALUE   i.e  7018:65001   )


Multiprotocol  UN/Reachable  (  optional non-transitive )
Multi_Exit_Discriminator  (  optional non-transitive )

Cluster_ID  (  optional non-transitive    using primary by  BGP router reflectors )

Now go out and do some BGP :)



Ken Felix
Freelance Network / Security Engineer
kfelix  ----a----t----socpuppets ---d---o---t---com


   ^      ^
=( *    * )=
        @
      /     \

How todo ipv6 T-Mobile APN ( Android )

T-mobile has support for  IPv6 & it's celluar devices and it's quite simple to enable on most  android devices. I will show you how & it's quite simple.


Simple as   1 2 3+reboot :)

In these next phone screen shots, I will show you how I configured "google Nexus4". AndroidOS 4.3. Andorid OS ( linux ) ,  has been  ipv6 aware ever since it creations iirc.


Okay 1st ;

Navigate to Settings; Wirelesss &Network Settings;

Next ;

click the Mobile networks

And find the  Access Point Names

On my phone I have the default "T-Mobile US",  and a backup that I made. The APN must be configured for ALL data  access, so don't change anything else in it , or make a backup and start with that or the original.

I'm  confident in my re-configuration skills , but if you  paranoid make a  backup!

Okay let's dive in;

We are going modify your active profile by toggling the APN roaming protocol

"Ipv4/Ipv6"

After doing this, you will need to reboot the phone to engage the AP and for data establishment. See how simple it was :)

You can use the  http://ip6.me website to review your ipv6 settings,  and http://test-ipv6.com for testing.


( My  IPv6 DNS failed btw )

Ken Felix
Freelance Network Security Engineer
kfelix ---a----t---- socpuppets ---dot----com


    ^   ^
=( $  $ )=
       @
       / \

IPv6 usage per Google Stats

IPv6 adoption per Google

http://www.google.com/ipv6/statistics.html#tab=ipv6-adoption


Cool information to see how google has been tracking ipv6 usage.It's interesting on the country tab, that Romania was shown.

Ken Felix
Freelance Network / Security  Engineer
kfelix  ---a-t----socpuppets ---d--o---t----com
     
   ^      ^
=( *   * )=
        @
        /  \

Nothing but "ipv6" Verizon MiFi

This summary is not available. Please click here to view the post.

fortigate advance reformat and install

Sometime in our fortigate firewalls, we develop issues with the image and flash storage. In this post we will look at a FWF60B and the recovering and restoring the image on the internal flash storage.

1st if  your firewall boots with the following error or any errors or just flat out don't boot;

This is a good sign or bad things ahead. But have no fear we can recover.

2nd, you will need to  pull the power cord and interrupt the boot process & reinstall and/or format

note:  here we will  reformat and then install a fresh image into the flash using TFTP-server. It will require that you have access to fortinet support for downloading the appropiate image

https://support.fortinet.com/login/UserLogin.aspx

Okay so let's reformat and install our new image;

tftp-server = located at 192.168.1.168
fortigate =  temporary configured at .188
netmask  = /24
image = FWF_60B-v400-buildXXXX-FORTINET.out ( xxxx =  the version build )

Okay that's simple. And as you can see  the unit will validate the  image and reboot the firewall after the recovering.

Lastly, if you suspect  hardware issues;  Fortinet provides a diagnostic image that  you can download and BOOT and run extended  diagnostics. These images are known as  HQIP and once again, require access to support @ fortinet.

http://emea.fortinet.net/fortinet/aht/index.php

So if you suspect hardware issues, grab the HQIP file for your model and run the diagnostics & before reinstalling the image.


Ken Felix
Freelance Network/Security Engineer

kfelix ----a--t----socpuppets ---.---com


   ^     ^
=( * O )=
      @
     / | \