OSPF LSA type

LSA type 1 – Router LSAs are sent from a router to other routers in the same area. It contains information regarding the routers interfaces in the same area, relevant interfaces IPs, its adjacent routers on those interfaces and sub networks

LSA type 2 – Network LSAs are generated by the DR on a multi access segment, and provides similar information to an LSA type 1 for the multi access segment and subnet which it belongs
LSA type 3 – Network Summary LSAs are generated by ABRs and contain the subnets & costs but omit the topological data from all subnets in one area and sent to another area via the ABR
LSA type 4 -ASBR summary LSAs are from ASBRs and are identical in structure to a type 3 LSA and sent when crossing an AS boundary
LSA type 5 -Are AS external LSAs which are originated by ASBRs and describe external networks
LSA type 6 – Is defined as a Group Membership LSA but not used in Cisco devices
LSA type 7 -NSSA External LSAs are generated by the ASBR in an NSSA area
LSA type 8 – Is defined as a External Attribute LSA but not used in Cisco devices
LSA types 9 to 11 – Defined as Opaque LSAs and are reserved for future expansion

ref.: http://communitystring.com/2008/07/ospf-lsa-types/

Area Type	Type 1 & 2 (within area)	Type 3 (from other areas)	Type 4	Type 5	Type 7
Standard & backbone	Yes	Yes	Yes	Yes	No
Stub	Yes	Yes	No	No	No
Totally stubby	Yes	No	No	No	No
NSSA	Yes	Yes	No	No	Yes
Totally stubby NSSA	Yes	No	No	No	Yes

ref.: https://learningnetwork.cisco.com/docs/DOC-7924

OSPF - Normal, Stub, Totally Stub and NSSA Area Differences

ref.: http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094aaa.shtml#definestub

Normal	None
Stub	No Type 5 AS-external LSA allowed
Totally Stub	No Type 3, 4 or 5 LSAs allowed except the default summary route
NSSA	No Type 5 AS-external LSAs allowed, but Type 7 LSAs that convert to Type 5 at the NSSA ABR can traverse
NSSA Totally Stub	No Type 3, 4 or 5 LSAs except the default summary route, but Type 7 LSAs that convert to Type 5 at the NSSA ABR are allowed

more information about LSA type:

http://raycheang.blogspot.com/2012/03/ospf-lsa-type.html

Juniper screen OS debug transaction flow

Capturing Debug flow basic:

Cl db

Set ff src-ip x.x.x.x dst-ip y.y.y.y

Set ff src-ip y.y.y.y dst-ip x.x.x.x

(where

x.x.x.x== client ip which is accessing the server y.y.y.y==public ip of server i.e VIP ip of the server)

debug flow basic

(Then initiate the concerned traffic from source x.x.x.x to y.y.y.y)

Get db str

Undebug all

Cl db

Capturing snoop detail

Cl db

Snoop filter ip src-ip x.x.x.x dst-ip y.y.y.y direction both Snoop detail len 1514 Snoop (and then press `y?)

(Then initiate the concerned traffic from source x.x.x.x to y.y.y.y)

Get db str

Snoop off

RHEL6 disable ipv6

Edit /etc/sysconfig/network
Change the following:
NETWORKING_IPV6=yes to NETWORKING_IPV6=no

Add a new file /etc/modprobe.d/ECS.conf containing
alias net-pf-10 off
alias ipv6 off

Stop the ipv6tables service
service ip6tables stop

Disable the ipv6tables service
chkconfig ip6tables off

After these changes, IPv6 will be disabled after the next reboot of your system.

verify ipv6 is disable
lsmod | grep ipv6
ifconfig

netstat

ref.: http://linuxnet.ch/groups/linuxnet/revisions/5b3a1/6/

Samba join domain win2008 + squid authentication with ntlm_auth

Step:

1. upgrade samba to 3.5 (for win2008)
2. edit /etc/samba/smb.conf
3. edit /etc/krb5.conf
4. edit /etc/pam.d/system-auth
5. add winbind option in /etc/nsswitch.conf
6. config iptables to allow 139,445,389 port, or allow all for testing
7. change selinux to permissive or disable just for testing
8. setup time, ensure no more than 5 min different with your DC 
9. startup smb, winbind, oddjobd
10. join domain
11. test with wbinfo, kinit, ntlm_auth, check if your linux host appear in AD\computer ou
12. edit /etc/squid/squid.conf
13. make sure squid group have permission to access /var/lib/samba/winbindd_privilege folder
14. Startup squid
15. client pc proxy config
16. client pc edit group policy, change Network security: LAN Manager authentication level:Send LM & NTLM - use NTLMv2 
17. client pc test to access internet with user authentication

For detail please check here:

EtherChannel config

==========PAgP Config:=============
Switch(config)# interface type mod/num
Switch(config-if)# channel-protocol pagp
Switch(config-if)# channel-group number mode {on | {{auto | desirable} [non-silent]}}

Example:
Switch(config)# port-channel load-balance src-dst-port
Switch(config)# interface range gig 3/1 – 4
Switch(config-if)# channel-protocol pagp
Switch(config-if)# channel-group 1 mode desirable non-silent
================================

=========LACP Config==============
Switch(config)# lacp system-priority priority
Switch(config)# interface type mod/num
Switch(config-if)# channel-protocol lacp
Switch(config-if)# channel-group number mode {on | passive | active}
Switch(config-if)# lacp port-priority priority

Example:
Switch(config)# lacp system-priority 100
Switch(config)# interface range gig 2/1 – 4 , gig 3/1 – 4
Switch(config-if)# channel-protocol lacp
Switch(config-if)# channel-group 1 mode active
Switch(config-if)# lacp port-priority 100
Switch(config-if)# exit
Switch(config)# interface range gig 2/5 – 8 , gig 3/5 – 8
Switch(config-if)# channel-protocol lacp
Switch(config-if)# channel-group 1 mode active
=================================

Debian/Ubuntu inter-vlan configuration

Suppose your switch is ready.
Install vlan package > add 802.1q module > config interface

1. apt-get install vlan

2. modprobe 8021q

3. vi /etc/network/interfaces
#add the following content, here I create 3 VLANs

auto vlan10 vlan20 vlan30

iface vlan10 inet static
address 192.168.10.1
netmask 255.255.255.0
mtu 1500
vlan_raw_device eth0

iface vlan20 inet static
address 192.168.20.1
netmask 255.255.255.0
mtu 1500
vlan_raw_device eth0

iface vlan30 inet static
address 192.168.30.1
netmask 255.255.255.0
mtu 1500
vlan_raw_device eth0

IDS vs. IPS Explained

Layered security is the key to protecting any size network, and for most companies, that means deploying both intrusion detection systems (IDS) and intrusion prevention systems (IPS). When it comes to IPS and IDS, it?s not a question of which technology to add to your security infrastructure ? both are required for maximum protection against malicious traffic. In fact, vendors are increasingly combining the two technologies into a single box.

IDS
At its most basic, an IDS device is passive, watching packets of data traverse the network from a monitoring port, comparing the traffic to configured rules, and setting off an alarm if it detects anything suspicious. An IDS can detect several types of malicious traffic that would slip by a typical firewall, including network attacks against services, data-driven attacks on applications, host-based attacks like unauthorized logins, and malware like viruses, Trojan horses, and worms. Most IDS products use several methods to detect threats, usually signature-based detection, anomaly-based detection, and stateful protocol analysis.

IPS
At its most basic, an IPS has all the features of a good IDS, but can also stop malicious traffic from invading the enterprise. Unlike an IDS, an IPS sits inline with traffic flows on a network, actively shutting down attempted attacks as they?re sent over the wire. It can stop the attack by terminating the network connection or user session originating the attack, by blocking access to the target from the user account, IP address, or other attribute associated with that attacker, or by blocking all access to the targeted host, service, or application.

In addition, an IPS can respond to a detected threat in two other ways. It can reconfigure other security controls, such as a firewall or router, to block an attack. Some IPS devices can even apply patches if the host has particular vulnerabilities. In addition, some IPS can remove the malicious contents of an attack to mitigate the packets, perhaps deleting an infected attachment from an email before forwarding the email to the user.

RADIUS Issues

Response authenticator based Shared Secret Attack
Attacker observes a valid access request packet and the associated return packet(access-accept/access-reject packet), then launch offline exhaustive attack on the shared secret.
They can guess shared secret by pre-compute MD5(Code+ID+length+RequestAuth+Attributes) and resume the hash once.

User-Password Attribute Based Shared Secret Attack

Attacker observes the traffic and try to authenticate to client with a known password, and capture the resulting Access-Request packet and XOR the User-password attribute with the password they provided to client. This results in the value of MD5(S+RA). RA is known in the client request packet, so attacker can launch offline exhaustive attack to get shared secret.

User-Password Based Password Attack
As the previous attack method, attacker can get the value of MD5(S+RA), and replay the modified access request packet as pretending a client. If server dosen't impose user based rate limits, this will allow the attacker to get the correct password.

Request Authenticator Based Attacks
The security of RADIUS depends on the generation of the RA(Request Authenticator)  field, but a lot of implementations using poor PRNG(pseudo random number generation) to generate the RA. If the client uses a PRNG that repeats values (or has a short cycle), the protocol ceases to provide the intended level of protection.

These attacks require the attacker to cause client to produce a particular identifier value. An attacker can insert a series of extra requests to the client, forcing the desired identifier. Even if the identifier were not generated in a readily attackable way, it would still only increase the work factor by 256 times.

Passive User-Password Compromise Through Repeated Request Authenticator
Build dictionary RA--User Password Attribure
If the attacker can sniff the traffic between the RADIUS client and the RADIUS server, they can passively produce a dictionary of Request Authenticators, and the associated (protected) User-Password attributes. If the attacker observes a repeated Request Authenticator, they can remove any influence of the Shared Secret from the first 16 octets of the passwords by XORing the first 16 octets of the protected passwords together. This yields the first 16 octets of the two (now unprotected) user passwords XORed together.

Active User-Password Compromise through Repeated Request Authenticators
Build dictionary RA--MD(S+RA)
Attacker authenticate many times using known passwords and intercept the generated Access-Request packets, extracting the RA and user-password attribute. Then XOR the known password with user-password attribute and be left with the MD5(S+RA) value. Finally, the attacker generates a dictionary of RA and associated MD5(S+RA) value.
Attacker can use this dictionary(RA--MD(S+RA)) to recover the first 16 octets from the protected region of the user password, since c1=p1 XOR MD5(S+RA).

Replay of Server Responses through Repeated Request Authenticators

Using dictionary RA--ID--associate server response

Attacker observe the client request, check RA and ID from the dictionary, then pretend as server the return the associate response to client.

DOS arising from the prediction of the Request Authenticators
Build dictionary predict RA values and associated server response, then response the client's valid request with access-reject packets, implement DOS.

RADIUS authentication procedure

RADIUS packet is below (from the RFC):

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Code      |  Identifier   |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                         Authenticator                         |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-

• The code establishes the type of RADIUS packet. The codes are:
  

Value	Description
1	Access-Request
2	Access-Accept
3	Access-Reject
4	Accounting-Request
5	Accounting-Response
11	Access-Challenge
12	Status-Server (experimental)
13	Status-Client (experimental)
255	Reserved

•  The identifier is a one octet value that allows the RADIUS client to match a RADIUS response with the correct outstanding request. it is usually implemented as a simple counter that is incremented for each request.
• The attributes section is where an arbitrary number of attribute fields are stored. The only pertinent attributes for this discussion are the User-Name and User-Password attributes. 
  

Initial client processing

The client creates an Access-Request RADIUS packet, including at least the User-Name and User-Password attributes.

The Access-Request packet's identifier field is generated by the client.

The Access-Request packet contains a 16 octet Request Authenticator in the authenticator field. This Request authenticator is a randomly chosen 16 octet string. 

This packet is completely unprotected, except for the User-Password attribute, which is protected as follows:

c1 = p1 XOR MD5(S + RA)
c2 = p2 XOR MD5(S + c1)
.
.
.
cn = pn XOR MD5(S + cn-1)

The User-Password attribute contains c1+c2+...+cn, Where + denotes concatenation.

Here S is shared secret in server or client, RA is psuedo-random 128bit request authenticator, p1,p2 and so on is 16 octet block by breaking the password

Server processing

• Extract the username and password using the same shared secret
• Validate the account
• Compute response authenticator which is MD5(code+ID+Length+RequestAuth+Attribute+secret), and send back the response packet to client
  

The server receives the RADIUS Access-Request packet and verifies the packet with shared secret first, it can go through a slightly modified version of the client's protection process on the User-Password attribute and obtain the unprotected password. It then uses its authentication database to validate the username and password. If the password is valid, the server creates an Access-Accept packet to send back to the client, otherwise, send back with Access-Reject packet. Both the Access-Accept packet and the Access-Reject packet use the same identifier value from the client's Access-Request packet, and put a Response Authenticator in the Authenticator field. The response authenticator = MD5(Code+ID+Length+RequestAuth+Attributes+Secret)

Client post processing

• Match ID
• Compute the Response Authenticator as the server performed
• Check the code field for the result
  

When the client receives a response packet, it attempts to match it with an outstanding request using the identifier field, then verifies the Response Authenticator by performing the same Response Authenticator calculation the server performed, and then comparing the result with the Authenticator field.

If the client received a verified Access-Accept packet, the username and password are considered to be correct, and the user is authenticated.

Eigrp - what happens after network command is issued

Here is EIGRP message

As soon as you configure network command on eigrp, following things happen in the given order:

Step 1. Hellos are sent.

Step 2. Receive Update.

Step 3. Run the dual and install the best route for the network learned in 2nd step.

Step 4. Send update about that interface.

An important observation here is that first of all, the above 4 steps are executed for directly connected networks.

You must be knowing this..i guess..

But notice their order..

Suppose there are two routers R1 and R2 connected via a serial link

Suppose there is a fast ethernet on each of the router R1 and R2..

Let the serial interfaces be named as R1S and R2S.

Let the fast ethernet interfaces be named as R1F and R2F

So R1 and R2 are connected via R1S and R2S...

As soon as u configure the network command, following things happen on Router R1..

a) Hello sent to R1F

b) Received update from R1F about that network

c) Run Dual and calculate the best path with the available data and feasible successor for the network learnt in step b. Enter the successor in routing table.

So you see, although local networks are already in the routing table, yet DUAL recalculates the best path and recreate the routing table with that network ..

d) Send update about network of R1F

"" At this stage ROUTING TABLE IS CREATED ( With one fastethernet network )...although Hellos are YET TO BESENT TO serial interface R1S. """

e) Hello sent to R1S

f) Received update from R1S about that network

g) Run Dual and calculate the best path and feasible successor for the network learnt in step f. Enter the successor in routing table.

h) Send update about network of R1S

After the above steps, neighbour adjancency is established with R2 if all the parameters are okay..

SO IT MEANS HELLOS ARE NOT IMMEDIATELY SENT ON ALL THE APPROPRIATE INTERFACES..

It is sent on one interface and then above 4 steps get executed in the above order.

Then hello is sent on 2nd interface and then again above 4 steps get executed in the given order.

Similar process goes on for the other interfaces that are enabled for receiving and sending EIGRP updates.

So routing table is created (though it is not complete) BEFORE hellos are sent out all the appropriate interfaces.

ref.:https://cisco.hosted.jivesoftware.com/message/5596

RIP Timers

RIP uses four different kinds of timers to regulate its performance:

Route update timer   Sets the interval (typically 30 seconds) between periodic routing updates
in which the router sends a complete copy of its routing table out to all neighbors.

Route invalid timer   Determines the length of time that must elapse (180 seconds) before a
router determines that a route has become invalid. It will come to this conclusion if it hasn’t
heard any updates about a particular route for that period. When that happens, the router will
send out updates to all its neighbors letting them know that the route is invalid.

Holddown timer   This sets the amount of time during which routing information is sup-
pressed. Routes will enter into the holddown state when an update packet is received that indi-
cated the route is unreachable. This continues either until an update packet is received with a
better metric or until the holddown timer expires. The default is 180 seconds.

Route flush timer   Sets the time between a route becoming invalid and its removal from the
routing table (240 seconds). Before it’s removed from the table, the router notifies its neigh-
bors of that route’s impending demise. The value of the route invalid timer must be less than
that of the route flush timer. This gives the router enough time to tell its neighbors about the
invalid route before the local routing table is updated.

ref.: Cisco Certified Network Associate Study Guide

Cisco router password recovery

step 1: press Ctrl+Break once the router boot up

step 2:
rommon 1>confreg 0x2142
rommon 2>reset

======================================================
remark:
0x2000 is boot default ROM software
0x0040 is ignore NVRAM
the last 2 is to specifies default boot file name

Router default register is 0x2102, you can check it by "sh version"