Impact of the FSMO roles on Acitve Directory and how to manipulate them

How is the loosing of FSMO's will reflect to usability of your domain?
Here is some consideration:
Schema role - if you loose this particular role, you can't change the schema. However, it's rarely necessary (for example, switching from Windows Server 2003 to Windows Server 2003 R2).
Domain Naming role - you won't be able to create new domains in the forest. In most cases, single domain is the only thing that should be sufficient.
RID role - if you don't create a lot of objects in AD you won't miss this role very soon.
Infrastructure role - if you only have a single domain, the chances are that everything will be OK.
PDC emulator - this role is critical. You will notice the problem very soon. There will be no time synchronization, the problem with managing group policies and user passwords will also exist.

By default, all FSMO roles are placed on first DC in the forest.

We can check which DC are currently holding the role by following next steps:
1. Download Support Tools form Windows Server 2003 CD, under ./Support/Tools
2. Under command prompt (new cmd form suptools) type "dumpfsmos"
That's an easy way to do this. There is also command line option from any Windows 2003 member server in a domain, however I'll skip this part.

We can move the roles between domain controllers or even restore them if one of the role holders DC are went down.

How to move or seize roles in AD:

Transferring/seizing PDC, Infrastructure and RID roles (GUI version):

1. Connect to desired DC with AD user and computers snapshot;
2. On domain object right click and select "operations master";
3. Click "change"...bla bla bla...always agree;

Transferring Schema FSMO (the user must be in the Schema Admins group):

1. Run "cmd" and then "regsvr32 schmmgmt.dll"
2. Run "mmc /a" and add "Active Directory Schema"
3. Click on object named "Active Directory Schema" and select "Operations master"

Transferring Domain Naming FSMO (the user must be in the Enterprise Admins group):

1. Open Active Directory Domains and Trusts
2. Right-click the "Active Directory Domains and Trusts" and select "Operations Master"
3. Select "Change"

Seizing master roles:

1. In cmd run "ntdsutil"
2. Type "Roles"
3. In "fsmo maintenance" type "Connections"
4. In "server connections" type "Connect to server /servername/"
5. Type "Quit" and you will return to "fsmo maintenance" prompt
6. Type "Seize /fsmo_name/ master (rid, domain naming, schema, infrastructure, pdc)
7. Type "Quit" untill you exit

The server first tries to transfer the particular role from the current master and if it's not succeeded, then it starts to creating the new role holder. Of course, if current master is offline (crashed?), then the process will hang for some period of time and show some number of errors, but eventually the new master will be created without any notification of success.

Understanding FSMO roles in Window Server 2003 Active Directory environment

There are number of functions that AD performs including authentication, user rights assignments, defining permissions to the shared resource etc. However, there are number of functions which stay in the shadow. These functions called Flexible Single Master Operation roles and they are playing very important part in AD.
There are 5 FSMO roles in AD:

Schema master role

Schema is like a class in programming, it defines all the properties of the objects. Implying to the AD, it would be properties like a name and surname of a user. Schema master DC controls all operations with schema and replicates any changes to other DC's. Only one schema master DC can exist in the whole forest.

Domain naming master role

The domain naming master DC controls the addition or removal of domains in the forest. Only the holder of this master role can add or remove domains from the forest. Only one domain naming master DC can exist in the whole forest.

RID master role

When a DC creates a security principal object such as a user or group, it attaches a unique Security ID (SID) to the object. This SID consists of a domain SID (the same for all SIDs created in a domain), and a relative ID (RID) that is unique for each security principal SID created in a domain.  Each DC in a domain is allocated a pool of RIDs that it is allowed to assign to the security principals it creates. When a DC's allocated RID pool falls below a threshold, that DC issues a request for additional RIDs to the domain's RID master. The domain RID master responds to the request by retrieving RIDs from the domain's unallocated RID pool and assigns them to the pool of the requesting DC. At any one time, there can be only one domain controller acting as the RID master in the domain.

PDC emulator role

The PDC emulator is necessary to synchronize time in an enterprise. Windows 2000/2003 includes the W32Time (Windows Time) service that is required by the Kerberos authentication protocol.
The PDC emulator of a domain is authoritative for the domain. The PDC emulator at the root of the forest becomes authoritative for the enterprise, and should be configured to gather the time from an external source. All PDC FSMO role holders follow the hierarchy of domains in the selection of their in-bound time partner.
In a Windows 2000/2003 domain, the PDC emulator role holder retains the following functions:

• Password changes performed by other DCs in the domain are replicated preferentially to the PDC emulator.
• Authentication failures that occur at a given DC in a domain because of an incorrect password are forwarded to the PDC emulator before a bad password failure message is reported to the user.
• Account lockout is processed on the PDC emulator.
• Editing or creation of Group Policy Objects (GPO) is always done from the GPO copy found in the PDC Emulator's SYSVOL share, unless configured not to do so by the administrator.
• The PDC emulator performs all of the functionality that a Microsoft Windows NT 4.0 Server-based PDC or earlier PDC performs for Windows NT 4.0-based or earlier clients.

There is only one PDC emulator DC for each domain.

Infrastructure role

When an object in one domain is referenced by another object in another domain, it represents the reference by the GUID, the SID (for references to security principals), and the DN of the object being referenced. The infrastructure FSMO role holder is the DC responsible for updating an object's SID and distinguished name in a cross-domain object reference. At any one time, there can be only one domain controller acting as the infrastructure master in each domain.

P.S. Tomorrow I would like to speak about how to manipulate the roles and why they are so critical in AD environment.

P.S.Thanks for this for saving me some typing time.

BGP synchronization

BGP Synchronization Rule
The BGP synchronization rule states that a BGP router should not use, or advertise to an external neighbor, a route learned by IBGP, unless that route is local or is learned from the IGP.

If synchronization is enabled and your autonomous system is passing traffic from one autonomous system to another, BGP should not advertise a route before all routers in your autonomous system have learned about the route via IGP. In other words, BGP and the IGP must be synchronized before networks learned from an IBGP neighbor can be used.

Routes redistribution and Administrative distance manipulation

I've seen the great example of problems with 2-way redistribution of routes between OSPF and RIP.

When we redistributing routes from RIP domain to OSPF on both P3R1 and P3R2, the curious thing happens. Let's say redistribution is configured on P3R1, then P3R2 will have only OSPF routes in it's routing table. The routes from RIP domain will have next-hop IP address on s0/0/0 interface of P3R1! Even loopback address on directly connected P3R4! This situation, of course, leads to suboptimal routing decisions.
One of the ways to fix the problem is to change administrative distance of OSPF routes learned via redistribution. We can rise the AD of these routes to make them appear less attractive then native RIP routes. In this way, native RIP routes will appear in the routing table instead of redistributed into OSPF routes.

hostname P3R2
!
router ospf 1
redistribute rip metric 10000 metric-type 1 subnets
network 172.31.0.0 0.0.255.255 area 0
distance 125 0.0.0.0 255.255.255.255 64
!
router rip
version 2
redistribute ospf 1 metric 5
network 10.0.0.0
no auto-summary
!
access-list 64 permit 10.3.1.0
access-list 64 permit 10.3.3.0
access-list 64 permit 10.3.2.0
access-list 64 permit 10.200.200.31
access-list 64 permit 10.200.200.32
access-list 64 permit 10.200.200.33
access-list 64 permit 10.200.200.34

Now the router will keep original AD of all native OSPF routes, except routes redistributed from OSPF(these routes will have AD of 125 > than native RIP routes).

The most important feature of using administrative distance to control route preference is that no path information is lost; in this example, the OSPF information is still in the OSPF database. If the primary path (via the RIP routes) is lost, the OSPF path reasserts itself, and the router maintains connectivity with those networks.

P.S. Routes must be in the routing table for them to be redistributed.

BSCI Preparation

OSPF network types:

OSPF defaults to point-to-point mode on the point-to-point subinterface and to nonbroadcast mode on the multipoint subinterface.

LSA Type 3: Summary LSA
The ABR sends type 3 summary LSAs. A type 3 LSA advertises any networks owned by an area to the rest of the areas in the OSPF autonomous system.

LSA Type 4: Summary LSA
A type 4 summary LSA is used only when an ASBR exists within an area. A type 4 LSA identifies the ASBR and provides a route to it. The link-state ID is set to the ASBR’s router ID. When an ABR receives a type 1 LSA from an ASBR, it sends out a type 4 summary LSA to advertise the presence of the ASBR to other areas.

Summary LSAs do not, by default, contain summarized routes. Therefore, by default, all subnets in an area will be advertised.

LSA Type 5: External LSA
Type 5 external LSAs describe routes to networks outside the OSPF autonomous system. Type 5 LSAs are originated by the ASBR and are flooded to the entire autonomous system.

Route summarization on ABR:

area area-id range address mask [advertise | not-advertise] [cost cost]

Route summarization on ASBR:

summary-address ip-address mask [not-advertise] [tag tag]

Areas
To configure stub area - use area area-id stub router configuration command.
To configure totally stub area - use no-summary parameter to the area area-id stub command at the ABR only!
To configure NSSA area, area area-id nssa [no-redistribution] [default-informationoriginate] [metric metric-value] [metric-type type-value] [no-summary] command is used.
Configuring OSPF Virtual Links

area area-id virtual-link router-id

area-id parameter is a number of an area where router-id resides.
OSPF authentication:
interface Serial0/0/1
ip address 192.168.1.101 255.255.255.224
ip ospf authentication message-digest
ip ospf message-digest-key 1 md5 secretpass


EIGRP

Hello timer on fast links - 5 seconds, on slow link (
Hold timer X3 hello timer, by default. Doesn't reflect the change of hello timer.

To pass default route ip default-network network-number must be used

When you configure the ip default-network command and specify a subnet, a static route (the ip route command) is generated in the router’s configuration; This can be confusing when you want to remove the default network; the configuration must be removed with the no ip route command, not with the no ip default-network command.

Summarization (same as RIP)

ip summary-address eigrp as-number address mask [admin-distance] interface configuration command.

Authentication
ip authentication mode eigrp 100 md5
ip authentication key-chain eigrp 100 R1chain

Quote:
1. A remote router extends the query about a network only if it has an exact match in the routing table.
2. Stub routers are not queried. Instead, hub routers connected to the stub router answer the query on behalf of the stub router.

Stub routers.
To configure a router as an EIGRP stub, use the eigrp stub [receive-only | connected | static |summary] router configuration command. A router configured as a stub with this command shares information about connected and summary routes with all neighbor routers by default.
The connected keyword permits the EIGRP stub routing feature to send connected routes. If a network command does not include the connected routes, it might be necessary to redistribute connected routes with the redistribute connected command under the EIGRP process.
The static keyword permits the EIGRP stub routing feature to send static routes. Redistributing static routes with the redistribute static command is still necessary.

IS IS
Level 1 intra-area routing is based on system IDs;
The area address is used to route between areas; the system ID is not considered.
The system ID is used to route within an area; the area address is not considered.

Routers on a LAN establish adjacencies with all other routers on the LAN.

Criteria for DIS selection are, first, highest priority and second, highest SNPA (recall that on LANs the SNPA is the MAC address). Cisco router interfaces have a default L1 and L2 priority of 64.


LSPs on broadcast media (LANs) are sent as multicast, and LSPs on point-to-point links are sent
as unicast.

Routers calculate ES reachability with a partial route calculation (PRC), based on the L1 and L2 SPF trees.

Example:

R2(config)#router isis

R2(config-router)#net 49.0001.0000.0000.0002.00

R2(config-router)#is-type {level-1 | level-1-2 | level-2-only}

R2(config)#interface FastEthernet0/0

R2(config-if)#ip router isis

R2(config-if)#isis circuit-type level-1

R2(config)#interface serial 0/0/1

R2(config-if)#ip router isis

R2(config-if)#isis circuit-type level-2-only

R2(config-if)#isis metric 35 level-2

R2(config-router)#summary-address address mask [level-1 | level-2 | level-1-2] [tag tag-number] [metric metric-value] router configuration command.

The summary-address command works on all IS-IS routers (L1 and L2), but it will only summarize the external IS-IS L1 routes (routes that were redistributed into IS-IS L1).

Manipulating routing updates

Routes must be in the routing table for them to be redistributed.
The default-metric router configuration command establishes the seed metric for all redistributed routes. Cisco routers also allow the seed metric to be specified as part of the redistribute command, either with the metric option or by using a route map.

When redistributing routing information, set the seed metric to a value larger than the largest metric within the receiving autonomous system, to help prevent suboptimal routing and routing loops.

The redistribute Command for RIP (EIGRP is the same)
Use the redistribute protocol [process-id] [match route-type] [metric metric-value] [route-map map-tag] router configuration command to redistribute routes into RIP.
When redistributing into RIP, the default metric is infinity except when redistributing a static route (including a default static route defined using the ip route 0.0.0.0 0.0.0.0 command) or connected route. In that case, the default metric is 1.
When redistributing a static or connected route into EIGRP, the default metric is equal to the metric of the associated static or connected interface.
The redistribute Command for OSPF
Use the redistribute protocol [process-id] [metric metric-value] [metric-type type-value] [route-map map-tag] [subnets] [tag tag-value] router configuration command to redistribute routes into OSPF.
When redistributing into OSPF, the default metric is 20, the default metric type is 2, and subnets are not redistributed by default.

The redistribute Command for IS-IS
Use the redistribute protocol [process-id] [level level-value] [metric metric-value] [metric-type type-value] [route-map map-tag] router configuration command to redistribute routes into IS-IS.
By default, routes are introduced into IS-IS as Level 2, with a metric of 0.

Default Routes and Routing Protocols
The ip default-network command is used to distribute default route information to other routers. For RIP, this command provides no functionality for the router on which it is configured.

For example, EIGRP does not redistribute the 0.0.0.0 0.0.0.0 default route by default. However, if the network 0.0.0.0 command is added to the EIGRP configuration, it redistributes a default route as a result of the ip route 0.0.0.0 0.0.0.0 interface command (but not as a result of the ip route 0.0.0.0 0.0.0.0 address or ip default-network commands).


Distribute Lists
(config-router)#distribute-list 7 out Serial0/0/0
!
access-list 7 permit 172.16.0.0 0.0.255.255
Route Maps
1. Only one condition listed on the same match statement must match for the entire statement to be considered a match.
2. However, all match statements within a route map statement must match for the route map to be considered matched.

BGP
BGP specifies that a BGP router can advertise to its peers in neighboring autonomous systems only those routes that it uses. This rule reflects the hop-by-hop routing paradigm generally used throughout the current Internet.
BGP does not let one AS send traffic to a neighboring AS, intending that the traffic take a different route from that taken by traffic originating in the neighboring AS.

To avoid routing loops within an AS, BGP specifies that routes learned through IBGP are never propagated to other IBGP peers.
By fully meshing all IBGP neighbors, when a change is received from an external AS, the BGP router for the local AS is responsible for informing all other IBGP neighbors of the change. IBGP neighbors that receive this update do not send it to any other IBGP neighbor, because they assume that the sending IBGP neighbor is fully meshed with all other IBGP speakers and has sent each IBGP neighbor the update.

The BGP synchronization rule states that a BGP router should not use, or advertise to an external
neighbor, a route learned by IBGP, unless that route is local or is learned from the IGP.

BGP sends BGP/TCP keepalives by default every 60 seconds.
The default hold time is 180 seconds.

BGP defines the following message types:
■ Open
■ Keepalive
■ Update
■ Notification

The attributes defined by BGP include the following:
■ Well-known mandatory attributes:
— AS-path
— Next hop
— Origin
■ Well-known discretionary attributes:
— Local preference
— Atomic aggregate
■ Optional transitive attributes:
— Aggregator
— Community
■ Optional nontransitive attribute:
— Multiexit-discriminator (MED)
In addition, Cisco has defined a weight attribute for BGP. The weight is configured locally on a router and is not propagated to any other BGP routers.

BGP Path Selection
0. Synchronized
1. Weight
2. Local Preference
3. Self Originated
4. AS-Path
5. Origin
6. MED
7. External (eBGP>iBGP)
8. IGP Cost
9. eBGP peering (oldest)
10. RID

EBGP Next Hop
For EBGP, the next hop is the IP address of the neighbor that sent the update.
IBGP Next Hop
For IBGP, the protocol states that the next hop advertised by EBGP should be carried into IBGP. It is very important, therefore, that Router C knows how to reach the subnet, advertised via IBGP as next-hop, either via an IGP or a static route; otherwise, it will drop packets because it will not be able to get to the next-hop address for that network. The IBGP neighboring router performs a recursive lookup to find out how to reach the BGP next-hop address by using its IGP entries in the routing table.

The MED indicates to external neighbors the preferred path into an AS. This is a dynamic way for an AS to try to influence another AS as to which way it should choose to reach a certain route if there are multiple entry points into the AS.
Unlike local preference, the MED is exchanged between autonomous systems. The MED is sent to EBGP peers; those routers propagate the MED within their AS, and the routers within the AS use the MED, but do not pass it on to the next AS.

Paths that the router originates have a weight of 32768 by default, and other paths have a weight of 0 by default.

Network command
The BGP network command determines which networks this router advertises. The list of network commands must include all networks in your AS that you want to advertise, not just those locally connected to your router. Note that the prefix must exactly match (address and mask) an entry in the IP routing table.
 If you configure network 192.168.0.0 mask 255.255.0.0 to advertise a CIDR block, BGP looks for 192.168.0.0/16 in the routing table. It might find 192.168.1.0/24 or 192.168.1.1/32; however, if it never finds 192.168.0.0/16, BGP does not announce the 192.168.0.0/16 network to any neighbors. In this case, you can configure the static route ip route 192.168.0.0 255.255.0.0 null0 toward the null interface so that BGP can find an exact match in the routing table.

Example:

router bgp 65000

neighbor 10.1.1.2 remote-as 64520

neighbor 192.168.2.2 remote-as 65000

neighbor 192.168.2.2 update-source loopback 0

neighbor 192.168.2.2 next-hop-self

network 172.16.10.0 mask 255.255.255.0

network 192.168.1.0

network 192.168.3.0

Example2. Influencing traffic entrance to AS:

neighbor 192.168.28.1 route-map med_65004 out
!
route-map med_65004 permit 10
match ip address 66
set metric 100
route-map med_65004 permit 100
set metric 200

Example3 Influencing outbound traffic:

neighbor 192.168.28.1 remote-as 65002
neighbor 192.168.28.1 route-map local_pref in
!
route-map local_pref permit 10
match ip address 65
set local-preference 400
!
route-map local_pref permit 20
!
access-list 65 permit 172.30.0.0 0.0.255.255

Configuring Weight
neighbor {ip-address | peer-group-name} weight weight router configuration command.
Local Preference
Router(config-router)# bgp default local-preference value
MED
Router(config-router)# default-metric value



Multicast

Link-local addresses (224.0.0.0/24);
Source-specific multicast (232.0.0.0/8);
GLOP (233.0.0.0/8);
Administratively scoped addresses (239.0.0.0/8) - private;
Globally scoped addresses (224.0.1.0–231.255.255.255 and 234.0.0.0–238.255.255.255)

IGMP
ip igmp snooping
ip igmp version {1 | 2 | 3}

ip multicast-routing global configuration command

ip pim sparse-dense-mode interface configuration command

ip pim send-rp-announce interface type scope ttl group-list access-list global configuration command on a router that you want to be an RP.
ip igmp join-group group-address interface configuration command. With this command, the router joins the specified group; the router accepts multicast packets in addition to forwarding them.
ip igmp static-group group-address interface configuration command. With this command, the router itself is a statically connected member of the group. The router does not accept the group’s packets itself, but only forwards them.

Making permanent mounts in Ubuntu 9.10

sudo gedit /etc/fstab

Add at the end of the file:

/dev/sda7 /media/work ext4 rw,user,auto 0 0

Number "/dev/sda7" can be found with df -h or in system monitor.
"/media/work" is the name of the folder that will be associated with device.
Other options are self-explaining.

P.S. Notice, that folder "/media/work" must exist and permission have to be set to allow appropriate actions for user. Otherwise, only "root" will be able to change something on the hdd.

Problems with clicking on Flash buttons in Ubuntu 9.10 with compiz

WORKAROUND 1: Disable compiz
WORKAROUND 2: Remove flashplugin-nonfree / flashplugin-installer and install from adobe
WORKAROUND 3: Open a terminal and enter:
gksudo gedit /usr/lib/nspluginwrapper/i386/linux/npviewer
Then add: export GDK_NATIVE_WINDOWS=1 before the last line of text.

Third workaround worked better for me.

VNC and multi-user environment in Ubuntu 9.10

To allow multiple users connect to our Ubuntu box, we need to install VNC Server with following commands:

sudo apt-get install vnc4server

It allows to use different sessions for multiple logins, so users can be separated from each other and won't fight for mouse as well as they won't see applications of each other :-)
Then we need to assign a password to our VNC logins. It can be done through running this command:

vncpasswd

Then we can launch a test desktop by running:

vncserver :1

Number here is a display number. Local user runs display :0 etc.
Now we can connect to it, by specifying either port number (::5901) or display number (:1) in remote VNC viewer. However, after logging in, the desktop won't be as usual X session. It will be presented as simple GUI with command line or just as a blank screen with cursor in form of cross.
Now we need to shutdown the session  with:

vncserver -kill :1

Next, edit ~/.vnc/xstartup. It should look similar to:

#!/bin/sh

# Uncomment the following two lines for normal desktop:
#unset SESSION_MANAGER
#exec /etc/X11/xinit/xinitrc

#[ -x /etc/vnc/xstartup ] && sh /etc/vnc/xstartup
#[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
#xsetroot -solid grey
#vncconfig -iconic &
#xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
#twm &

unset SESSION_MANAGER
sh /etc/X11/xinit/xinitrc

Now we can start the vncserver :1 again and connect to it. Pay attention to user, under which vncserver have been started. It means, that if we have started server under our current user, the remote login will be as the same user.
To enable different user to log in, we should create another user in Ubuntu, install SSH server and make all the steps from above. Then we can first SSH to our Ubuntu box, log in under different user (which we want to use for our remote VNC session), in console session type vncserver :[number] and then launch vnc viewer on remote client and connect to the session just created.

To secure traffic on it's way, we can tunnel it through the SSH connection. For this we need to add SSH tunnel at the Putty menu by specifying source port as "5900" (if we are connecting to display :0) and destination "localhost:5900". Then connect to the server and leave Putty screen as is. Now we just need to connect via VNC to localhost:5900 and our traffic will be tunneled to SSH connection. That's it.


Whew, sounds like a lot of routine, but I haven't found the way to automate it yet.
The good thing is that at least it's working  ;-)

P.S. To get multiple instance of Firefox (or any other Mozilla application) running simultaneously when we logged on the same user as local session, we need to set the environment variable MOZ_NO_REMOTE=1 before starting Firefox.
To do this just use:
export MOZ_NO_REMOTE=1

Firestarter - another great GUI front-end to iptables

We can use apt-get install firestarter to get firestarter running. After startup wizard, our rules will be imported to the iptables. Even if firestarter's gui isn't running, firewall is actually working so we don't have to worry about it.
We can check firewall status by running:

sudo /etc/init.d/firestarter status

By default, GUI won't be started after computer reboot.
To override this, we should make a simple configuration changes to some files.
First of all, we need to add Firestarter to System - Preferences - Startup Applications. The add an entry stating:  

sudo firestarter --start-hidden

However, the password have to be specified to run this command, because it runs with root privileges. Moreover, we can't specify the password since this is logging script, so it just won't work at all. To get it working, we should edit /etc/sudoers file with any text editor or via sudo visudo command which is preferable.Then add the following line to the end of the file or it won't work:

[username] ALL=NOPASSWD: /usr/sbin/firestarter

That's it! Now are done and can start using firewall!

P.S. It's not recommended to start GUI automatically on system startup since it's a security breach.
P.P.S. Uninstalled it  after 1 day of using. Allows only 2 network interfaces to be configured as local or outside, making other interfaces to work improperly. For example, pings won't be allowed from those unconfigured interfaces at all. Maybe more inconveniences are present, but I haven't tested it any further. Moreover, after removing the Firestarter, ufw stopped working and I had to install Firestarter back and then remove it completely with apt-get remove purge command. It didn't heal ufw, so I had to completely remove it too and then install it back. Sounds ugly, isn't it?

UFW - simply great firewall for Linux

UFW is a very simple and powerful firewall which allows us to configure our policies in minutes!
Moreover, it allows us to configure forwarding traffic between interfaces and even NAT!
We can check UFW status by typing sudo ufw status or even just sudo ufw to see the list of available options.
By default, all outbound traffic is permitted. UFW is stateful firewall, so it tracks connections via maintaining connection table. Returning traffic permitted to pass through the firewall only if corresponding connection is in the table. Or simply, traffic allowed to return only if connection were originated from the inside network.
To open ports in the firewall, so inbound connections can be allowed, we have to add the rules. It's simple:

sudo ufw allow port number[/tcp|udp]

or 

sudo ufw deny port number[/tcp|udp] to block open ports.

To disable logging we can execute

sudo ufw logging off

Here are steps to configure routing and NAT.

First, packet forwarding need to be enabled.
We need to modify 2 configuration files:
1.  /etc/default/ufw change DEFAULT_FORWARD_POLICY to "ACCEPT".
2.  /etc/ufw/sysctl.conf uncomment /net/ipv4/ip_forward=1
After previous steps our Linux machine will begin to forward packets between it's interfaces!
Only NAT configuration left and it pretty straightforward.
We need to add rules to the /etc/ufw/before.rules file. We need to add the following string right to the top of the file after the header comments:

# nat Table rules
*nat
:POSTROUTING ACCEPT [0:0]

# Forward traffic from eth1 through eth0.
-A POSTROUTING -s 192.168.0.0/24 -o eth0 -j MASQUERADE

# don't delete the 'COMMIT' line or these nat table rules won't be processed
COMMIT

To enable Port Forwarding, also add the following string before COMMIT keyword. If ports to be forwarded are different on NAT device and destination then simply add :[portNumber]

-A PREROUTING -i eth1 -p tcp --dport 3389 -j DNAT --to 192.168.139.101:[portNumber]

Of course, ip networks and interface names should be replaced with appropriate. eth0 in this example is our outside interface on which translation will be performed. 192.168.0.0/24 subnet is our internal subnet which requires translation.
Only restarting the firewall left.

sudo ufw disable && sudo ufw enable

Using ACL's in a switch

vlan access-map map-name [sequence]

 math {ip | mac} {acl-name | acl - number}

 action {drop | forward | redirect type mod/num}

 exit

vlan filter map-name vlan-list vlan-list

Troubleshooting:

show vlan filter

show vlan access-map

Private Vlan's

First, we need to define secondary vlan's. We have to do it first, because they will be mapped to the primary vlan in a latter step.

vlan 201

 private-vlan community

vlan 202

 private-vlan isolated

Next, we need to identify primary vlan's and they association with secondary vlans

vlan 2

 private-vlan primary

 private-vlan association  201, 202

Now we need to identify switch ports. First, let's configure the ports connected to the user devices.

int fa0/1

 switchport mode private-vlan host

 switchport private-vlan host-association 2 201

int range fa0/2 - 3 

 switchport mode private-vlan host

 switchport private-vlan host-association 2 202

Now we need to identify any promiscuous ports on the switch. Routers will be connected to those ports.

int fa0/24

 switchport mode private-vlan promiscuous

 switchport private-vlan mapping 2 201, 202

How to check system specification in Ubuntu

sudo lshw -html >> /home/igro/Desktop/1.html

Ntpdate + Crontab

Crontab is used to automate repetitive tasks.
We can use command crontab -e to enter the editor mode and then add tasks we need.
crontab -l shows scheduled commands for particular user.

Ntpdate is a simple program that allows us to synchronise system time once. It's not so sophisticated as ntpd daemon that continuously synchronising system time, running in background.
It's usage is also simple: ntpdate servername

It can be really handy to combine it with crontab to synchronise system clock periodically.

Just do the following:
sudo crontab -e
@hourly /usr/sbin/ntpdate 1.it.pool.ntp.org

This crontab job should be executed as root or the date won't be synchronised.
Also, the path for the program in the crontab job should be a full path. Even so ntpdate servername command would work from terminal execution, it won't from crontab job. For crontab we have to specify the full path, e.g. /usr/sbin/ntpdate servername. That is a general rule for crontab.
To check the full path of the command, we can use which command.
For example, which ntpdate.

Crontab  example:
0 */2 * * * /home/igro/Desktop/backupGNS

Following string allows us to execute backupGNS script every two hours.

Installing Packet Tracer i386 in Linux 64-bit.

I've downloaded PacketTracer-5.2.bin and my first intention was to simply install it with: chmod +x .....bin   ./....bin However, the installation complains about inconsistent architecture. The workaround is to extract .deb package from this .bin file and then to force it to install it under 64-bit operating system.
For this to be accomplished, we need to begin the installation of .bin file and after EULA has been displayed, navigate to /tmp/selfextract.[randomNumber] and get the .deb file from this directory. Then simply force it to install without checking the architecture.
sudo dpkg -i --force-all ./PacketTracer-5.2-u.i386.deb

Enjoy!

How to mount and why do we need it

Sometimes, it would be useful for us to add a path to a script that contains spaces.
Something like: "/home/igro/Ubuntu One".
For example tar can't accept path like this one.
As a workaround we can mount this path as a different folder on disk and use it as in a path script as a path.

For example:
mount -B "/igro/home/Ubuntu One" "/NewFolderName"
And after that:
tar /NewFolderName <- this is not an actual command, but the idea is about the path used.
Don't forget, that we need to create the destination folder prior to use it in mount command.

Executing .bin files

.bin files are similar to installation files in Windows.
1. First we should add an execution permission with chmod +x /[path]/[filename]
2. Navigate to file's folder.
3. Execute the file ./[filename]

Securing Switch Access

If an interface is undergoing the restrict or protect condition, we might need to clear the learned MAC addresses so that a specific host can use the switch port. We can clear a MAC address or the complete port cache with the following command:

Switch# clear port-security dynamic [address mac-addr | interface type mod/num]

Checking port states:

show port-security interface

show interfaces status err-disabled

show port-security

=================================================

Steps to enable dot1x authentication:

Switch(config)# aaa new-model

Switch(config)# radius-server host {hostname | ip-address} [key string]

Switch(config)# aaa authentication dot1x default group radius

Switch(config)# dot1x system-auth-control

Switch(config)# interface type mod/num
Switch(config-if)# dot1x port-control {force-authorized | forceunauthorized | auto}

Here, the 802.1x state is one of the following:
force-authorized—The port is forced to always authorize any connected client. No authentication is necessary. This is the default state for all switch ports when 802.1x is enabled.
force-unauthorized—The port is forced to never authorize any connected client. As a result, the port cannot move to the authorized state to pass traffic to a connected client.
auto—The port uses an 802.1x exchange to move from the unauthorized to the authorized state, if successful. This requires an 802.1x-capable application on the client PC.

If the switch should expect to find multiple hosts present on the switch port, use the following interface configuration command:

Switch(config-if)# dot1x host-mode multi-host

Verifying dot1x operations:

show dot1x all

=================================================

DHCP Snooping
When DHCP snooping is enabled, switch ports are categorized as trusted or untrusted. Legitimate DHCP servers can be found on trusted ports, whereas all other hosts sit behind untrusted ports. A switch intercepts all DHCP requests coming from untrusted ports before flooding them throughout the VLAN. Any DHCP replies coming from an untrusted port are discarded because they must have come from a rogue DHCP server. In addition, the offending switch port automatically is shut down in the Errdisable state. DHCP snooping also keeps track of the completed DHCP bindings as clients receive legitimate replies. This database contains the client MAC address, IP address offered, lease time, and so on.

Configuration:

Switch(config)# ip dhcp snooping

Switch(config)# ip dhcp snooping vlan vlan-id [vlan-id]

By default, all switch ports are assumed to be untrusted so that DHCP replies are not expected or permitted. Only trusted ports are allowed to send DHCP replies.

Switch(config)# interface type mod/num 

Switch(config-if)# ip dhcp snooping trust 

For untrusted ports, an unlimited rate of DHCP requests is accepted. If we want to rate-limit DHCP traffic on an untrusted port, use the following interface configuration command: 

Switch(config)# interface type mod/num  

Switch(config-if)# ip dhcp snooping limit rate rate

DHCP option-82 feature is enabled by default. We can enable or disable option-82 globally with the following configuration command:
Switch(config)# [no] ip dhcp snooping information option

Verifying:
Switch# show ip dhcp snooping [binding]
We can use the binding keyword to display all the known DHCP bindings that have been overheard.

Example:

Switch(config)# ip dhcp snooping
Switch(config)# ip dhcp snooping vlan 104
Switch(config)# interface range fastethernet 0/35 – 36
Switch(config-if)# ip dhcp snooping limit rate 3
Switch(config-if)# interface gigabitethernet 0/1
Switch(config-if)# ip dhcp snooping trust

IP Source Guard
IP Source Guard works by making use of the DHCP snooping database and static IP source binding entries. If DHCP snooping is configured and enabled, the switch learns the MAC and IP addresses of hosts that use DHCP. Packets arriving on a switch port can be tested for one of the following conditions:
■ The source IP address must be identical to the IP address learned by DHCP snooping or a static entry. A dynamic port ACL is used to filter traffic. The switch automatically creates this ACL, adds the learned source IP address to the ACL, and applies the ACL to the interface where the address is learned.
■ The source MAC address must be identical to the MAC address learned on the switch port and by DHCP snooping. Port security is used to filter traffic.
If the address is something other than the one learned or statically configured, the switch drops the packet.

For the hosts that do not use DHCP, you can configure a static IP source binding with the following configuration command:
Switch(config)# ip source binding mac-address vlan vlan-id ip-address interface type mod/num
Here, the host’s MAC address is bound to a specific VLAN and IP address, and is expected to be found on a specific switch interface. 

Next, enable IP source guard on one or more switch interfaces with the following configuration commands:

Switch(config)# interface type mod/num

Switch(config-if)# ip verify source [port-security]

Verify the IP source guard status:
Switch# show ip verify source [interface type mod/num]

Dynamic ARP Inspection
When an ARP reply is received on an untrusted port, the switch checks the MAC and IP addresses reported in the reply packet against known and trusted values. A switch can gather trusted ARP information from statically configured entries or from dynamic entries in the DHCP snooping database.
If an ARP reply contains invalid information or values that conflict with entries in the trusted database, it is dropped and a log message is generated. This action prevents invalid or spoofed ARP entries from being sent and added to other machines’ ARP caches.
We can configure DAI by first enabling it on one or more client VLANs with the following configuration command:
Switch(config)# ip arp inspection vlan vlan-range 
By default, all switch ports associated with the VLAN range are considered to be untrusted. We should identify trusted ports as those that connect to other switches.
Switch(config)# interface type mod/num
Switch(config-if)# ip arp inspection trust

If we have hosts with statically configured IP address information, there will be no DHCP message exchange that can be inspected. Instead, we can configure an ARP access list that defines static MAC-IP address bindings that are permitted:
Switch(config)# arp access-list acl-name
Switch(config-acl)# permit ip host sender-ip mac host sender-mac [log]
[Repeat the previous command as needed]
Switch(config-acl)# exit
Now the ARP access list must be applied to DAI with the following configuration command:
Switch(config)# ip arp inspection filter arp-acl-name vlan vlan-range [static]

Finally, we can specify further validations on the contents of ARP reply packets. By default, only the MAC and IP addresses contained within the ARP reply are validated. This doesn’t take the actual MAC addresses contained in the Ethernet header of the ARP reply. To validate that an ARP reply packet is really coming from the address listed inside it, you can enable DAI validation with the following configuration command:
Switch(config)# ip arp inspection validate {[src-mac] [dst-mac] [ip]}

Verification:

show ip arp inspection 

 

Syslog in Ubuntu

To be able to accept remote syslog message, I installed sysklog ( k in the middle isn't a typo) and changed /etc/defaults/syslog. I added -r options so syslog accepts not only local, but also remote logs.
Then just restart the syslog daemon with:
/etc/init.d/sysklogd restart
Also, we should add a rule to ufw to allow incoming connections on UDP port 514:
sudo ufw allow 514/udp

Done!

GNS3 in Ubuntu 9.10

Today was a day of Linux exploration. I made a dual boot for Windows 7 + Ubuntu 9.10 and it works pretty well so far (if doesn't take into account that I almost don't have a free space left on HDD). Let's summarize today's findings:

1. GNS3 can and better be downloaded as a source. However, we can just start it without any compilation.
2. Also we need a python-qt4 for GNS3 to work properly. apt-get install python-qt4.
3. Dynamips should be dowloaded as a binaries. We can just put it to the GNS folder and that's all.
4. Wireshark can be downloaded as a package via Synaptic Packager Manager (don't forget to launch it as a root or you won't see any interfaces available for capture). We can add gksudo key before path to WireShark in shortcut.
5. GNS3 should be launched with root privileges to be able to connect routers to tap interfaces. sudo .[path]/gns3 or create a shortcut and add the following to the "command" option  gksudo /[path]/gns3
6. On of the most important things that I've learned today is that tap interfaces play a role of loopback interfaces in Windows. They can be created with following commands:
• tunctl -t tap1
  ifconfig tap1 192.168.139.1 netmask 255.255.255.0 up 
7. These commands require uml-utilities package. So: apt-get install uml-utilities
8. But they will be gone after rebooting, so to automate the process  we can create a script with commands beyond and place it in /etc/init.d directory. Than we need to add privileges to execute the file with sudo chmod +x /etc/init.d/[file name]. And as a final step we need to execute sudo update-rc.d [file name] defaults. It will add our script to startup scripts.  

At this point we are almost done. Our routers can ping tap interfaces. However, Linux won't route the traffic between interfaces. As a consequence we can't communicate with an outside world or even with VirtualBox guests bridged with another tap interfaces.

In order to make it possible, we should enable routing in Linux. Also we can enable NAT.
I've done it via UFW. Great simple firewall. Actually, it's an front-end to iptables.
Here are steps to configure routing and NAT.

First, packet forwarding need to be enabled.
We need to modify 2 configuration files:
1.  /etc/default/ufw change DEFAULT_FORWARD_POLICY to "ACCEPT".
2.  /etc/ufw/sysctl.conf uncomment /net/ipv4/ip_forward=1
After previous steps our Linux machine will begin to forward packets between it's interfaces!
Only NAT configuration left and it pretty straightforward.
We need to add rules to the /etc/ufw/before.rules file. We need to add the following string right to the top of the file after the header comments:

# nat Table rules
*nat
:POSTROUTING ACCEPT [0:0]

# Forward traffic from eth1 through eth0.
-A POSTROUTING -s 192.168.0.0/24 -o eth0 -j MASQUERADE

# don't delete the 'COMMIT' line or these nat table rules won't be processed
COMMIT

Of course, ip networks and interface names should be replaced with appropriate. eth0 in this example is our outside interface on which translation will be performed. 192.168.0.0/24 subnet is our internal subnet which requires translation.
Only restarting the firewall left.
sudo ufw disable && sudo ufw enable

After all we have done, it's just left to enjoy our speedy routers in Linux! Cheers!


P.S. Here is the way to enable communication with an outside world from Blindhog.net.

To configure communication with outside world, we can't just connect router to the eth0 interface in the cloud. First we have to create tap interface and bridge it to the real interface eth0 and then connect router to the tap interface. Following is a copy/paste from blindhog.net blog:

Here are the steps to manually create a bridge group.
======================================

1. Create a tap interface
   sudo tunctl -t tap0
2. Remove ip addressing and set eth0 and tap0 to promiscuous mode
   sudo ifconfig tap0 0.0.0.0 promisc up
   sudo ifconfig eth0 0.0.0.0 promisc up
3. Create a new bridge interface
   sudo brctl addbr br0
4. Add tap0 and eth0 to the bridge group
   sudo brctl addif br0 tap0
   sudo brctl addif br0 eth0
5. Enable the bridge interface and give it an ip address
   sudo ifconfig br0 up
   sudo ifconfig br0 10.10.10.99/24
6. Configure the default route
   sudo route add default gw 10.10.10.254

Here are the steps to reverse the changes (these can be copied and pasted in)
======================================
sudo ifconfig br0 down
sudo brctl delif br0 eth0
sudo brctl delif br0 tap0
sudo brctl delbr br0
sudo tunctl -d tap0
sudo ifconfig eth0 up
sudo ifconfig eth0 10.10.10.99/24
sudo route add default gw 10.10.10.254
 
Add the following to your /etc/network/interfaces config file if you are using static addressing.
======================================
auto br0
iface br0 inet static
address 10.10.10.99
netmask 255.255.255.0
gateway 10.10.10.254
bridge-ports eth0 tap0
pre-up ifconfig eth0 0.0.0.0 promisc up
pre-up ifconfig tap0 0.0.0.0 promisc up
 
Add the following to your /etc/network/interfaces config file if you are using dhcp.
======================================
auto br0
iface br0 inet dhcp
bridge-ports eth0 tap0
pre-up ifconfig eth0 0.0.0.0 promisc up
pre-up ifconfig tap0 0.0.0.0 promisc up

SWITCH memo

EtherChannel
PAgP has 2 modes: auto (passive) and desirable (active).
LACP has modes active and passive
In active/desirable switch actively trying to form etherchannel and in auto/passive mode switch waits for the other side to negotiate.

If PAgP configured for a silent auto mode, the link will eventually come up (after bundling it to a port-channel) even without device configured for an etherchannel on the other end of the link. However, the link won't join Port-channel. It will be up, but not as a part of a channel. If the link was configured with silent desirable mode, it will form a channel without hearing any PAgP packet from the opposite side. It allows to form a channel with not a PAgP capable devices like servers etc.
If non-silent command was configured in Switch(config-if)# channel-group number mode {on | {{auto | desirable} [non-silent]}} then it will be required for each port to receive PAgP packets before adding them to a channel. If PAgP isn’t heard on an active port, the port remains in the up state, but PAgP reports to the Spanning Tree Protocol (STP) that the port is down.

If show commands, then show ETHERCHANNEL

If interface command, then int PORT-CHANNEL

If configuration commands, then CHANNEL-XXXX

Spanning Tree Protocol

Catalyst switches offer the PortFast feature, which shortens the Listening and Learning states to a negligible amount of time. When a workstation link comes up, the switch immediately moves the PortFast port into the Forwarding state. Spanning-tree loop detection is still in operation, however, and the port moves into the Blocking state if a loop is ever detected on the port. We can configure PortFast as a global default, affecting all switch ports with a single command. All ports that are configured for access mode (nontrunking) will have PortFast automatically enabled.

The UplinkFast feature on Catalyst switches enables leaf-node switches or switches at the ends of the spanning-tree branches to have a functioning root port while keeping one or more redundant or potential root ports in Blocking mode. When the primary root port uplink fails, another blocked uplink immediately can be brought up for use. UplinkFast works by keeping track of possible paths to the root bridge. Therefore, the command is not allowed on the root bridge switch. The goal is to keep UplinkFast limited to leaf-node switches that are farthest from the root. First, the switch’s bridge priority is raised to 49,152, making it unlikely that the switch will be elected to root bridge status. The port cost of all local switch ports is incremented by 3000, making the ports undesirable as paths to the root for any downstream switches.
When an uplink on a switch goes down, UplinkFast makes it easy for the local switch to update its bridging table of MAC addresses to point to the new uplink. However, UplinkFast also provides a mechanism for the local switch to notify other upstream switches that stations downstream (or within the access layer) can be reached over the newly activated uplink. The switch accomplishes this by sending dummy multicast frames to destination 0100.0ccd.cdcd on behalf of the stations contained in its Content-Addressable Memory (CAM) table. The MAC addresses are used as the source addresses in the dummy frames, as if the stations actually had sent them. The idea is to quickly send the multicast frames over the new uplink, giving upstream hosts a chance to receive the frames and learn of the new path to those source addresses.


BackboneFast works by having a switch actively determine whether alternative paths exist to the root bridge, in case the switch detects an indirect link failure. A switch detects an indirect link failure when it receives inferior BPDUs from its designated bridge on either its root port or a blocked port.
Normally, a switch must wait for the Max Age timer to expire before responding to the inferior BPDUs. However, BackboneFast begins to determine whether other alternative paths to the root bridge exist according to the following port types that received the inferior BPDU:
■ If the inferior BPDU arrives on a port in the Blocking state, the switch considers the root port and all other blocked ports to be alternative paths to the root bridge.
■ If the inferior BPDU arrives on the root port itself, the switch considers all blocked ports to be alternative paths to the root bridge.
■ If the inferior BPDU arrives on the root port and no ports are blocked, however, the switch assumes that it has lost connectivity with the root bridge. In this case, the switch assumes that it has become the root bridge, and BackboneFast allows it to do so before the Max Age timer expires.
If the local switch has blocked ports, BackboneFast begins to use the Root Link Query (RLQ) protocol to see whether upstream switches have stable connections to the root bridge. First, RLQRequests are sent out. If a switch receives an RLQRequest and either is the root bridge or has lost connection to the root, it sends an RLQ Reply. Otherwise, the RLQ Request is propagated on to other switches until an RLQ Reply can be generated. On the local switch, if an RLQ Reply is received on its current root port, the path to the root bridge is intact and stable. If it is received on a nonroot port, an alternative root path must be chosen. The Max Age timer immediately is expired so that a new root port can be found. BackboneFast is simple to configure and operates by short-circuiting the Max Age timer when needed. Although this function shortens the time a switch waits to detect a root path failure, ports still must go through full-length Forward Delay timer intervals during the Listening and Learning states.

When used, BackboneFast should be enabled on all switches in the network because BackboneFast requires the use of the RLQ Request and Reply mechanism to inform switches of Root Path stability.

Root Guard
The Root Guard feature was developed as a means to control where candidate root bridges can be connected and found on a network. Basically, a switch learns the current root bridge’s bridge ID. If another switch advertises a superior BPDU, or one with a better bridge ID, on a port where Root Guard is enabled, the local switch will not allow the new switch to become the root. As long as the superior BPDUs are being received on the port, the port will be kept in the root-inconsistent STP state.When the superior BPDUs no longer are received, the port is cycled through the normal STP states to return to normal use.

BPDU Guard should be used along with PortFast feature, to prevent inadvertent connection of bridging devices to an access port. However, BPDU Guard won't prevent loops, if non-STP capable device is connected to a port. BPDU Guard feature puts port to a err-disable state, if BPDU is received on a port.

Why is it so terrifying to get a bridge or switch on a Portfast enabled port? It is because port will transition from a blocking to a forwarding state without any delay (forward delay, max age etc), so a bridging loop might occur. That's why Portfast enabled ports should be "guarded" by a BPDU Guard feature (Guard enables on a port as soon as Portfast is enabled). When the BPDUs no longer are received, the port still remains in the errdisable state.

UDLD and LoopGuard. Suppose, the switch port is in Blocking state and it receives BPDU's from a designated port on a segment. If, BPDU's stop arrive, then switch assumes, that there is no STP device on that segment (like PC is connected), so it can safely move it to Forwarding state and make it designated on this segment. However, suppose, that something filtering BPDU's on their way to the switch, but there is still a device actively sending them on the opposite side of the link. This means, that switch should NOT transit port from a blocking to a forwarding state, however it will happen if LoopGuard feature isn't enabled on this port.
When enabled, LoopGuard keeps track of the BPDU activity on nondesignated ports. This feature will move port to a loop-inconsistent state if BPDU's go missing (effectively preventing loops to occur). After BPDU's are received on a port again, Loop Guard allows to port to move through the normal STP states and become active.
UDLD works like pings on fiber-optic links where link can become partly damaged and become unidirectional. So on the one side switch could stop to receive BPDU's, however it can send data across the link. A unidirectional link poses a potential danger to STP topologies because BPDUs will not be received on one end of the link. If that end of the link normally would be in the Blocking state, it will not be that way for long. A switch interprets the absence of BPDUs to mean that the port can be moved safely through the STP states so that traffic can be forwarded. However, if that is done on a unidirectional link, a bridging loop forms and the switch never realizes the mistake.
The objective behind UDLD is to detect a unidirectional link condition before STP has time to move a blocked port into the Forwarding state. To do this, the target time must be less than the Max Age timer plus two intervals of the Forward Delay timer, or 50 seconds. UDLD can detect a unidirectional link after about three times the UDLD message interval (45 seconds total, using the default). If none of those messages is echoed back, the port is placed in the Errdisable state so that it cannot be used (in case of aggressive mode, otherwise syslog message is generated).

HSRP/VRRP/GLBP
HSRP. Only the standby (the one with the second-highest priority) router monitors the hello messages from the active router.
HSRP mac address 0000.0c07.acxx, where xx represents the HSRP group number as a two-digit hex value. HSRP sends its hello messages to the multicast destination 224.0.0.2 (“all routers”) using UDP port 1985. Priority and group numbers:

• 0 to 255

VRRP MAC address is of the form 0000.5e00.01xx, where xx is a two-digit hex VRRP group number. VRRP sends its adverts to the multicast destination address 224.0.0.18 (VRRP), using IP protocol 112. Priority and group numbers:

•  group numbers range from 0 to 255;  priorities range from 1 to 254.

AVG sends periodic hello messages to each of the other GLBP peers. In addition, it expects to receive hello messages from each of them.
GLBP MAC addresses always have the form 0007.b4xx.xxyy. The 16-bit value denoted by xx.xx represents six zero bits followed by a 10-bit GLBP group number. The 8-bit yy value is the virtual forwarder number. Priority and group numbers

• group numbers range from 0 to 1023. Priority can be 1 to 255
• The maximum weight can range from 1 to 254 (default 100).

SWITCH Commands

Here I am going to post configurations commands related to the certain exam topics.

■ Vlan trunking configuration

Switch(config)# interface type mod/port

Switch(config-if)# switchport

Switch(config-if)# switchport trunk encapsulation {isl | dot1q | negotiate}

Switch(config-if)# switchport trunk native vlan vlan-id

Switch(config-if)# switchport trunk allowed vlan {vlan-list | all | {add | except | remove} vlan-list}

Switch(config-if)# switchport mode {trunk | dynamic {desirable | auto}}

If you decide to configure both ends of a trunk link as a fixed trunk (switchport mode trunk), you can disable DTP completely so that these frames are not exchanged. To do this, add the switchport nonegotiate command to the interface configuration.

■VTP should be in a first section, but i guess, that it's easy enough to configure it.

vtp mode server

vtp password SECRET

vtp version 1/2

vtp domain DOMAIN

Troubleshooting:

show vtp status

show vtp password

 
■EtherChannel
Load-balance distribution:

port-channel load-balance  METHOD

The following methods exist:

 PAgP configuration:
Switch(config)# interface type mod/num 
Switch(config-if)# channel-protocol pagp
Switch(config-if)# channel-group number mode {on | {{auto | desirable} [non-silent]}}
By default, PAgP operates in silent submode. The silent submode listens for any PAgP packets from the far end, looking to negotiate a channel. If none is received, silent submode assumes that a channel should be built anyway, so no more PAgP packets are expected from the far end.
Even if the two interfaces are using PAgP auto silence mode, the link will still eventually come up, although not as a channel.

LACP configuration:

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

First, the switch should have its LACP system priority defined (1 to 65,535; default 32,768). If desired, one switch should be assigned a lower system priority than the other so that it can make decisions about the EtherChannel’s makeup. We can configure more interfaces in the channel group number than are allowed to be active in the channel. This prepares extra standby interfaces to replace failed active ones. The lacp port-priority command allows us to configure a lower port priority (1 to 65,535; default 32,768) for any interfaces that must be active, and a higher priority for interfaces that might be held in the standby state. Otherwise, we can use the default scenario, in which all ports default to 32,768 and the lower port numbers (in interface number order) are used to select the active ports.
Troubleshooting:

show etherchannel port-channel
show etherchannel summary
show etherchannel load-balance

■Spanning Tree Protocol
We can configure PortFast as a global default, affecting all switch ports with a single command. All ports that are configured for access mode (nontrunking) will have PortFast automatically enabled.

Switch(config)# spanning-tree portfast default

Switch(config)# spanning-tree uplinkfast [max-update-rate pkts-per-second]

Switch(config)# spanning-tree backbonefast

Switch(config-if)# spanning-tree guard root
Switch(config)# spanning-tree portfast bpduguard default
Switch(config-if)# [no] spanning-tree bpduguard enable
Switch(config)# spanning-tree loopguard default
Switch(config-if)# [no] spanning-tree guard loop
Switch(config)# udld {enable | aggressive | message time seconds}

Switch(config-if)# udld {enable | aggressive | disable}
Switch(config)# spanning-tree portfast bpdufilter default
Switch(config-if)# spanning-tree bpdufilter {enable | disable}
The default keyword indicates that BPDU filtering will be enabled automatically on all ports that have PortFast enabled. If PortFast is disabled on a port, then BPDU filtering will not be enabled there.

Troubleshooting

Switch# show spanning-tree

Switch# show spanning-tree detail

Switch# show spanning-tree [vlan vlan-id] summary

Switch# show spanning-tree [vlan vlan-id] root

Switch# show spanning-tree [vlan vlan-id] bridge

Switch# show spanning-tree interface type port

Switch# show spanning-tree uplinkfast/backbonefast

We can display switch ports that Root Guard (and not only Root Guard) has put into the root-inconsistent state with the following command: 

Switch# show spanning-tree inconsistentports
Switch# show udld [type mod/num]
Switch# udld reset - reenable ports that UDLD aggressive mode has errdisabled.

Very useful commands not only for spanning tree:

Router#show int status

Router#show int status err-disabled

MST - ?

■HSRP

Switch(config-if)# standby group priority priority
Switch(config-if)# standby group timers [msec] hello [msec] holdtime
Switch(config-if)# standby group preempt [delay [minimum seconds] [reload seconds]]
Switch(config-if)# standby group authentication string   - plain text auth
Switch(config-if)# standby group authentication md5 key-string [0 | 7] string
Switch(config-if)# standby group track type mod/num [decrementvalue]
Switch(config-if)# standby group ip ip-address [secondary]

Troubleshooting

Router# show standby [brief] [vlan vlan-id | type mod/num] 

■VRRP

Troubleshooting

Switch# show vrrp [brief]

■GLBP

Switch(config-if)# glbp group priority level

Switch(config-if)# glbp group preempt [delay minimum seconds]

Hello messages are sent at hellotime intervals, with a default of 3 seconds. If hellos are not received from a peer within a holdtime, defaulting to 10 seconds, that peer is presumed to have failed.

Switch(config-if)# glbp group timers [msec] hellotime [msec] holdtime

The redirect timer is used to determine when the AVG will stop using the old virtual MAC address in ARP replies. The AVF corresponding to the old address continues to act as a gateway for any clients that try to use it.
When the timeout timer expires, the old MAC address and the virtual forwarder using it are flushed from all the GLBP peers. The AVG assumes that the previously failed AVF will not return to service, so the resources assigned to it must be reclaimed.

Switch(config-if)# glbp group timers redirect redirect timeout

GLBP also can use a weighting function to determine which router becomes the AVF for a virtual MAC address in a group. Each router begins with a maximum weight value (1 to 254). As specific interfaces go down, the weight is decreased by a configured amount. GLBP uses thresholds to determine when a router can and cannot be the AVF. If the weight falls below the lower threshold, the router must give up its AVF role. When the weight rises above the upper threshold, the router can resume its AVF role. By default, a router receives a maximum weight of 100. If you want to make a dynamic weighting adjustment, GLBP must know which interfaces to track and how to adjust the weight.

Switch(config)# track object-number interface type mod/num {line-protocol | ip routing}

The maximum weight can range from 1 to 254 (default 100).

Switch(config-if)# glbp group weighting maximum [lower lower] [upper upper]

Switch(config-if)# glbp group weighting track object-number [decrement value]

Switch(config-if)# glbp group load-balancing [round-robin | weighted | hostdependent]

Switch(config-if)# glbp group ip [ip-address [secondary]]

Troubleshooting

show glbp [brief]

■Using ACL's in a switch

vlan access-map map-name [sequence]

 math {ip | mac} {acl-name | acl - number}

 action {drop | forward | redirect type mod/num}

 exit

vlan filter map-name vlan-list vlan-list

Troubleshooting:

show vlan filter

show vlan access-map

ASA Image

In this article, I will show you how to emulate Cisco ASA using Qemu. Once again, please note that ASA is not provided and will not be. So please don’t ask. Also be aware that ASA does not 100% work in Qemu but that’s enough to play with it.

This Howto is still a draft and has been tested only on Linux.

Installation

First compile and patch Qemu as you would do for running JunOS. This will give us pcap, lcap and UDP tunnels (i.e. GNS3/Dynamips connections) capabilities.

Then obtain ASA itself. If you are smart and patient you will find it. I used asa802-k8.bin for my installations. As far as I know, nobody has been able to run ASA > version 8.2 (ASA keeps rebooting).

The next step is to get an initrd and a Linux kernel (inside the initrd) from your ASA image to use them with Qemu and also fix the initrd for our needs. The initrd is zipped and archived in the ASA image, we have to extract it.

There are 2 ways, manually or using a tool I created.

Manual method

Create an hexadecimal dump of your image:

hexdump -C asa802-k8.bin > asa802-k8.hex

Search for the ZIP header:

grep “1f 8b 08 00 1d” asa802-k8.hex 001228b0 1f 8b 08 00 1d 3d 73 46 00 03 ec 3a 6d 54 14 57 |…..=sF…:mT.W|

We can see that the ZIP file starts at offset 1228b0.
Let’s find the image size:

ls -la asa802-k8.bin -rwxr-xr-x  1 root  staff  14524416 26 Nov 20:14 asa802-k8.bin 14524416 bytes.

Now we need to find out where in the file we can start extracting the ZIP part.

echo "14524416 ; ibase=16 ; last - 1228B0" | bc | tail -n 1 13334352

Extract the zipped part of the ASA image:

tail -c 13334352 asa802-k8.bin > asa802-k8.gz

Decompress it with gzip:

gzip -d asa802-k8 gzip: asa802-k8.gz: decompression OK, trailing garbage ignored

Make a temp directory and go into it so we can extract the files contained in the uncompressed archive file (the initrd):

mkdir tmp ; cd tmp

Now extract the archive with cpio (you must have the administrator rights to successfully extract device files).

cpio -i --no-absolute-filenames --make-directories < ../asa802-k8

Copy the Linux kernel to your previous directory:

cp vmlinuz ../asa802-k8.kernel

Before compressing back the initrd, create the following script in asa/scripts/first_start.sh
This script formats the 256 MB flash on first start to be used by ASA. Loads the network drivers modules for Intel e100 (i82559er in Qemu) and Intel e1000 cards and activates the network interfaces to be used in ASA. I noticed that if we immediately start ASA after this first boot, it freezes (don’t really know why but it seems the system do something and slow down during the first minute …). The next time you start the system, the script will still load the activate the network interfaces and automatically start ASA.

#!/bin/sh   FIRST_START=no if test ! -e /mnt/disk0/lina_monitor then fdisk /dev/hda << EOF n p 1 5 979 t 4 w EOF mkdosfs -F 16 /dev/hda1 mount -o umask=0000,noatime,check=s,shortname=mixed /dev/hda1 /mnt/disk0 cp /asa/bin/lina /mnt/disk0/lina cp /asa/bin/lina_monitor /mnt/disk0/lina_monitor FIRST_START=yes fi modprobe e100 modprobe e1000 ifconfig eth0 up ifconfig eth1 up ifconfig eth2 up ifconfig eth3 up ifconfig eth4 up ifconfig eth5 up if test $FIRST_START = yes then echo "" echo "" echo "This is your first boot, please wait about 1 min and then type the following commands:" echo "cd /mnt/disk0" echo "/mnt/disk0/lina_monitor" echo "" echo "Please note to use the following command under ASA to save your configs:" echo "copy run disk0:/.private/startup-config" echo "" exit fi cd /mnt/disk0 /mnt/disk0/lina_monitor

In order for the script to be loaded at startup, edit etc/init.d/rcS and change /asa/bin/lina_monitor by /asa/scripts/first_start.sh
Now you can compress all the file and have the initrd ready to use in Qemu:

find . | cpio -o -H newc | gzip -9 > ../asa802-k8.initrd.gz

Using ASA with Qemu

Create a FLASH (this is a virtual hard disk).

qemu-img create FLASH 256M

Then you can start Qemu.

qemu -hda FLASH -kernel asa802-k8.kernel -hdachs 980,16,32 \ -initrd asa802-k8.initrd.gz -m 512 -no-kqemu -nographic -append \ "console=ttyS0,9600n8 hda=980,16,32 bigphysarea=16384 auto nousb ide1=noprobe"

TODO: networking of ASA. Very similar with JunOS emulation.

Using ASA with GNS3

To be completed:
In Preferences -> Qemu -> Qemuwrapper section:
Set the path to Qemuwrapper (can be found in the GNS3 package)
Set the working directory (e.g. /tmp).
Set the path to your patched Qemu in “Path to Qemu”
In ASA section:
Set the paths to your initrd and kernel.
Drag and Drop an ASA symbol on the scene, start the firewall and telnet to it.