Filter redistribution with route maps

One way to filter prefixes is with a route map. When used for filtering prefixes, a route map works like an access list. It has multiple statements that are read in a sequential order. Each statement can be a deny or permit and can have a match clause for a variety of attributes, such as the route or a route tag. You can also include route attributes in each statement that will be set if the match clause is met.


Set a default seed metric

Under any routing protocol, you can specify a default seed metric to be used for redistribution instead of, or in addition to, setting metrics on a per-protocol basis. A seed metric is a protocol-independent feature of the Cisco IOS Software that is usually configured when redistributing into distance-vector protocols.

R2(config)# router ospf 1
R2(config-router)# default-metric 10000

Verify the new metric in the R3 routing table. It might take some time for the new metric to propagate.
R3# show ip route ospf

Allow one-way redistribution.

configure OSPF to redistribute into RIP under the RIP configuration prompt with the redistribute ospf process metric metric command, where process is the OSPF process number, and metric is the default metric with which you want to originate the routes into RIP. If you do not specify a default metric in RIP, it gives routes an infinite metric and they are not advertised.
R2(config)# router rip
R2(config-router)# redistribute ospf 1 metric 4

Verify the redistribution with the show ip protocols command.

Redistributing: rip, ospf 1

Suppress routes using prefix lists

Sometimes you might not want to advertise certain networks out a particular interface, or you might want to filter updates as they come in. This is possible with distance-vector routing protocols, such as RIP or EIGRP. However, link-state protocols are less flexible, because every router in an area is required to have a synchronized database as a condition for full adjacency.

Distribute lists can be used with either access lists or prefix lists to filter routes by network address. With prefix lists, they can also be configured to filter routes by subnet masks.

To create a prefix list or add a prefix list entry, use the ip prefix-list command in global configuration mode.
ip prefix-list {list-name | list-number} {deny network/length | permit network/length} [ge ge-length] [le le-length]

The ge keyword represents the “greater than or equal to” operator. The le keyword represents the “less than or equal to” operator. If both the ge and le keywords are omitted, the prefix list is processed using an exact match.

R1(config)# ip prefix-list RIP-OUT permit
R1(config)# ip prefix-list RIP-OUT deny le 24
R1(config)# ip prefix-list RIP-OUT permit le 32
Line 1 of the prefix list permits the summary route and nothing else, because no other route can match that network address with a mask of exactly 22 bits.
Line 2 denies all prefixes with a network address in the block of addresses that have subnet masks from 22 bits to 24 bits. This removes exactly four network addresses matching the 22, 23, and 24 bits in length of the subnet mask. Line 2 would deny the summary route you created if Line 1 did not explicitly permit the summary route.
Line 3 allows all IPv4 prefixes that are not explicitly denied in previous statements of the prefix list.

Passive Interfaces

For security reasons and to reduce unnecessary traffic, RIP updates should not be propagated into the OSPF domain. You can disable sending updates with the passive-interface interface_type interface_number router configuration command

Making an interface in RIP passive only disables updates from being sent through RIP. It does not affect routes being received through it.

Putting a RIPv2 interface in passive mode saves the router from sending multicast RIP packets out an interface that has no neighbors.

To verify RIPv2 send advertisements out loopback interfaces: monitor the output of the debug ip rip command to verify your answer. Configure all loopbacks from which RIPv2 is sending advertisements in passive state with the passive-interface command.

When running RIPv2, implement passive interfaces as a common practice to save CPU processor cycles and bandwidth on interfaces that do not have multicast RIPv2 neighbors.

Passive interfaces save CPU cycles, router memory, and link bandwidth by preventing broadcast and multicast routing updates on interfaces that have no neighbors. In link-state protocols, adjacencies must be formed before routers exchange routing information. The passive-interface command in OSPF configuration mode prevents an interface from sending or processing OSPF packets on that interface.

You can use the passive-interface command to control the advertisement of routing information.
The command enables the suppression of routing updates over some interfaces while it allows
updates to be exchanged normally over other interfaces.
With most routing protocols, the passive-interface command restricts outgoing advertisements
only. However, when used with Enhanced Interior Gateway Routing Protocol (EIGRP), the effect is
slightly different. With EIGRP running on a network, the passive-interface command stops both
outgoing and incoming routing updates, since the effect of the command causes the router to stop
sending and receiving hello packets over an interface.

Enabling debug logging for the Net Logon service

Microsoft tool to trace and track which system/users is having account lockout problem either caused by user or by worm_Conficker. Account Lockout and Management Tools

After downloading the executable file, you should extract it to any folder. Before using the tool, you would need to active debug logging on your Domain Controller first.

To active, you need to add a registry key into you Domain Controller. Here is the link to Microsoft webpage.

 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\DBFlag hexadecimal value of 2080FFFF to enable 0 to disable.

Or you could use this command to enable and disable Net Logon Service and debugging too. Remember to restart the netlogon service after enable/disable of the debug logging.

Enable debug logging -> nltest /dbflag:0x2080ffff
Disable debug logging -> nltest /dbflag:0x0

Stop Net Logon Service -> net stop netlogon
Start Net Logon Service -> net start netlogon

Nltest is included as part of Windows Server 2008 and is also available as part of the Support Tools packages on the installation media for Windows Server 2003, Windows XP, and Windows 2000.

The netlogon.log is normally under debug folder in the Windows system directory of your Domain Controller which you enable the debug logging.

To delete the netlogon.log file after debugging, you would need to stop the netlogon service before deletion. After deletion you can start back the net logon service again. The commands to do so is as follows.

net stop netlogondel netlogon.lognet start netlogon