Saturday, January 6, 2018

OSPF LSA TYPES AND AREAS

  • LSA 1 (Router LSA)
Generated by all routers in an area to describe their directly attached links (Intra-area routes). These do not leave the area.
  • LSA 2 (Network LSA)
Generated by the DR of a broadcast or Nonbroadcast segment to describe the neighbors connected to the segment. These do not leave the area.
  • LSA 3 (Summary LSA)
Generated by the ABR to describe a route to neighbors outside the area. (Inter-area routes)
  • LSA 4 (Summary LSA)
Generated by the ABR to describe a route to an ASBR to neighbors outside the area.
  • LSA 5 (External LSA)
Generated by ASBR to describe routes redistributed into the area. These routes appear as E1 or E2 in the routing table. E2 (default) uses a static cost throughout the OSPF domain as it only takes the cost into account that is reported at redistribution. E1 uses a cumulative cost of the cost reported into the OSPF domain at redistribution plus the local cost to the ASBR.
  • LSA 6 (Multicast LSA)
Not supported on Cisco routers.
  • LSA 7 (NSSA External LSA)
Generated by an ASBR inside a NSSA to describe routes redistributed into the NSSA. LSA 7 is translated into LSA 5 as it leaves the NSSA. These routes appear as N1 or N2 in the ip routing table inside the NSSA. Much like LSA 5, N2 is a static cost while N1 is a cumulative cost that includes the cost upto the ASBR.


Area types

STUB AREA
Instead of propagating external routes (type 5 LSAs) into the area, the ABR injects a type 3 LSA containing a default route into the stub area.

For an area to become a stub, all routers belonging to it must be configured to operate as such. Stub routers and non-stub routers will not form adjacencies.
Router(config-router)# area 10 stub
 
 
Totally stubby areas 
can only contain type 1 and 2 LSAs, and a single type 3 LSA. The type 3 LSA describes a default route,
substitutes all external and inter-area routes.
 
Router(config-router)# area 10 stub no-summary
 
NSSA
AN ASBR cannot form an adjacency in a stub area.  To work around this NSSA were created. An NSSA makes use of type 7 LSAs, which are essentially type 5 LSAs in disguise. This allows an ASBR to advertise external links to an ABR, which converts the type 7 LSAs into type 5 before flooding them to the rest of the OSPF domain.

An NSSA can function as either a stub or totally stubby area. To designate a normal (stub) NSSA, all routers in the area must be so configured:
Router(config-router)# area 10 nssa 
 
To expand an NSSA to function as a totally stubby area, eliminating type 3 LSAs (bar 1), all of its ABRs must be configured with the no-summary parameter:

Router(config-router)# area 10 nssa no-summary 
 
 
 
Summary
  • Standard areas can contain LSAs of type 1, 2, 3, 4, and 5, and may contain an ASBR. The backbone is considered a standard area.
  • Stub areas can contain type 1, 2, and 3 LSAs. A default route is substituted for external routes.
  • Totally stubby areas can only contain type 1 and 2 LSAs, and a single type 3 LSA. The type 3 LSA describes a default route, substituted for all external and inter-area routes.
  • Not-so-stubby areas implement stub or totally stubby functionality yet contain an ASBR. Type 7 LSAs generated by the ASBR are converted to type 5 by ABRs to be flooded to the rest of the OSPF domain.
 
 
 







capability vrf-lite

This command struck me as a bit of an oddity.    In summary with VRF processing the OSPF route is tagged with the DN bit when redistributed from BGP. The DN bit prevents loops when there is BGP to OSPF redistribution.   This can cause problems if the route is received on another device that is not a PE router performing such a fucntion.  As such this loop prevention mechanism can be turned off with the 'capability vrf-lite' command.

router ospf 1 vrf ric
capability vrf-lite

DOT1Q Tunnelling

802.1q tunnelling


802.1Q tunnelling expands VLAN space within a provider network. It enables customer vlans to be run over a service provider network using a single VLAN. A port configured to support 802.1q tunnelling is know as a ‘tunnel’ port.

When configuring tunnelling, a tunnel port is assigned to a VLAN that is dedicated to tunnelling. Each service provider customer requires a separate VLAN, but that VLAN supports all customer VLANS.

VLAN tunnelling is transparent to the customer. Their service provider facing trunk is configured as a standard dot1q trunk. The service provider interface is set up as a tunnel port and assigned an access VLAN id, unique for the customer. In this respect the configuration at each end of the CE to PE link is unusual because it is not symmetrical i.e. it does NOT match from a CE and PE perspective.

As 802.1q tagged traffic arrives at the service provider switch it is further encapsulated in another 802.1q tag or the ‘customer’ tag. Upon exiting the service provider infrastructure the tag is removed before transiting to the customer.



PE configuration



Int fa0/1

switchport access vlan 100

switchport mode dot1q-tunnel



vlan dot1q tag native



Over and above 802.1q tunnelling, the service provider may chose to run L2 protocol tunnelling as well i.e. for protocols cdp, stp and vtp. These features can be implemented independently of 802.1Q tunnelling. L2 protocol tunnelling is enabled by protocol on the tunnel ports that are connected to the CE edge switches.

Int fa0/1

L2protocol-tunnel stp

L2protocol-tunnel cdp

L2protocol-tunnel vtp



gavin

Hi Richard, thanks for the reply. I thought you were doing the bootcamp after my test for some reason, hope it's going well. Anyway thanks for the input and reassurance that you were thinking along similar lines. One question actually, does it look like Harith is still covering the same labs we did in December? I've tried emailing him a few times but haven't heard anything back from him.

Study has been going well, I have put in a tonne of time since starting back after Christmas am spending these 2 weeks just practicing lots of config and troubleshooting labs from my workbooks , as well as brushing up on things I knew I was week on like EEM and OER for example. I actually had a look at your blog and read over some of your posts for the OER :) Hopefully it will be enough that I can at least give the lab my best shot, and if I fail then hopefully I will have still come close enough that I won't be too discouraged from trying again.

Anyway, enjoy the 2 weeks, I hope that it will be the difference to get you across the line and I'll get in touch next week to discuss my lab.

Gavin

> From: rpcapps@hotmail.com
> To: gavdbyrne@hotmail.com
> Date: Wed, 22 Feb 2012 07:06:44 +0000
> Subject: Re: Question about EEM
>
> Hi gavin
>
> Things going well thanks. In mk at winnet on 3rd day of 12 day bootcamp. It is a chance to go through things at slower pace.
>
> I have spent quite a bit of time on eem and your solution looks good to me(that said we haven't covered eem yet on bootcamp) My thoughts were to set term length as well. If I have any other suggestions b4 end of week I will email.
>
> Hope your 2 weeks study is going well and the very best for monday.
>
> Regards
> Richard
> Sent from my BlackBerry smartphone from Virgin Media
>
> -----Original Message-----
> From: Gavin Byrne
> Date: Tue, 21 Feb 2012 23:22:44
> To:
> Subject: Question about EEM
>
> Hey Richard, how are things going? Quick question for you, did you ever try work out the EEM question that was on one of the 2 sample labs we did during the bootcamp in December, I am able to figure out most of it so far but just can't work out how to meet the requirement to only send the first 10 lines of the show processes cpu sorted 5min command. The only thing I could think of was to set the length to 10 in the console line settings? Any ideas?
>
> This is what I have so far anyway...


event manager applet CPU1
event tag 1.0 snmp oid cpmCPUTotal5min get-type exact entry-op gt entry-val 60 entry-type value poll-interval 60
action 0.1 cli command "show processes cpu sorted 5min"
action 1.0 mail server "198.2.5.10" to "engineer@cisco.com" from "EEM@cisco.com" subject "CPUAlert5min" body "$_cli_result"

event manager applet CPU2
event tag 1.0 snmp oid cpmCPUTotalTable.1.5 get-type exact entry-op gt entry-val 60 entry-type value poll-interval 60
action 0.1 cli command "show processes cpu sorted 5min"
action 1.0 mail server "198.2.5.10" to "engineer@cisco.com" from "EEM@cisco.com" subject "CPUAlert5min" body "$_cli_result"

event manager applet CPU3
event tag 1.0 snmp oid 1.3.6.1.4.1.9.9.109.1.1.1.1.5 get-type exact entry-op gt entry-val 60 entry-type value poll-interval 60
action 0.1 cli command "show processes cpu sorted 5min"
action 1.0 mail server "198.2.5.10" to "engineer@cisco.com" from "EEM@cisco.com" subject "CPUAlert5min" body "$_cli_result"

> Thanks,
> Gavin




I guess this is the right solution.

event manager applet CPU5Min
event snmp oid "cpmCPUTotalTable.1.8" get-type next entry-op ge entry-val "5" poll-interval 10
action 1 cli command "enable"
action 2 cli command "terminal length 12"
action 3 cli command "show process cpu sort 5min" pattern "--More--"
action 5 mail server "198.168.1.150" to "engineer@ciso.com" from "EEM@cisco.com" subject "CPU ALert 5Min" body "$_cli_result"



to test replace action 5 by:

action 5 syslog msg "$_cli_result"


I tested this on GNS3 with syslog, can anyone test this using real smtp server, if terminal length should be 12 or 10?


event manager applet CPU
 event snmp oid cpmCPUTotal5minRev get-type exact entry-op ge entry-val "60" entry-type value poll-interval 60

 action 1.0 cli command "show processes cpu sorted 5min" pattern "--More--"
 action 1.5 mail server "198.2.5.10" to "engineer@cisco.com" from "EEM@cisco.com" subject "CPUAlert5min" body "$_cli_result"


To test



event manager applet TEST3
event none

action 0.5 cli command "terminal length 12"
action 1.0 cli command "show processes cpu sorted 5min" pattern "--More--"
action 1.5 syslog msg "$_cli_result"
!
end




event manager applet CPU
 event snmp oid cpmCPUTotal5minRev get-type exact entry-op ge entry-val "60" entry-type value poll-interval 60
 action 0.5 cli command "terminal length 12"
 action 1.0 cli command "show processes cpu sorted 5min" pattern "--More--"
 action 1.5 syslog msg "$_cli_result"
 action 2.0 mail server "198.12.5.10" to "engineer@cisco.com" from "EEM@cisco.com" subject "CPUAlert5min" body "$_cli_result"










ASA Connection Profiles and Policies

Setting up Remote Access VPN to the Cisco ASA.

When a user connects to a Cisco ASA to establish a remote access VPN there a number of factors/features that come into play.  Here i provide a high level summary of the steps that are taken by the ASA.

The user can connect either direct to the IP address of the ASA or to a defined IP address URL combination.  If connecting direct to the IP address the user may select
their required Tunnel Group (provided the ASA has been configured to allow this).   It is URL or Tunnel Group that is used by the ASA to establish any custom connection profile and user authentication parameters applied.  Fallback is for the ASA to use the Default Connection Profile.

Post User authentication the ASA applies Post Login Policies to nail down the access afforded to the user plus any DAP policies required.   Policies applied here can be determined by the user profile, user group profile, user connection profile or by the default connection profile.



Wednesday, January 3, 2018

Checkpoint Firewall Useful Commands



By way of a memory jogger a brief collection  of Checkpoint CLI Firewall commands i have found invaluable.




clusterXL_admin up/down     
used to control active/standby firewall in cluster

cphaprob stat                           
shows failover status

cplic print                                 
shows status of licences

fw stat                                       
shows loaded policy

cpview                                      
shows performance indicators

netstat -ni                                 
check for packet drops on interfaces

fw getifs                                    
quick orientation on firewall interfaces

top                                             
review processes and resources being used

Tuesday, January 2, 2018

Checkpoint File Captures

A brief self reminder on how to execute packet captures on Checkpoint Firewalls.
There are much more detailed guides out there, but here are the basics.

TCPDUMP
True packet capture capable of generating a PCAP file for wireshark
tcpdump host {a.b.c.d} -i eth1 -w {filename}.pcap
few examples
tcpdump src a.b.c.d                     Show all traffic from ip
tcpdump dst a.b.c.d                     Show all traffic to ip
tcpdump net a.b.c.0/24                Look at traffic to and from 1.2.3.0 network
tcpdump port 123                        NTP example
tcpdump udp and dst port 53      specify protocol combined with DNS filter
tcpdump portrange 1000-1100      


FW MONITOR
Not as verbose/low level as tcpdump but good enough for a quick snapshot

#packets with IP a.b.c.d as SRC or DST
fw monitor -e "accept host(a.b.c.d);"

# all packets between pair of src and dst ips
fw monitor -e "accept src a.b.c.d and dst w.x.y.z;"

# UPD traffic from or to DNS
fw monitor -e "accept udp and (sport=53 or dport=53);"