Thursday, March 31, 2011
Saturday, March 26, 2011
- Router A
- access-list 1 permit 188.8.131.52 255.255.255.0
- access-list 1 permit 184.108.40.206 255.255.255.0
- access-list 2 permit 220.127.116.11 255.255.255.0
- route-map route-tag permit 10
- match ip address 1
- set tag 111 --tag the 1st two remote sites with 111
- route-map route-tag permit 20
- match ip address 2
- set tag 222 -- tag the 3rd remote site with 222
- route-map route-tag permit 30 -- without this, all other routes will be dropped
- router ospf 1
- redistribute bgp 65001 subnets route-map route-tag -- redistribute ISP routes into IGP
- Router B
- route-map tag-filter deny 10
- match tag 111 -- filter off sites with tag 111
- route-map tag-filter permit 20
- match tag 222 --permit only sites with tag 222
- router ospf 2
- distribute-list route-map tag-filter in
To verify, perform the necessary "show ip route" commands on both router A and B to ensure the route entries are in order. Do note that tagging does not work with BGP. The alternative in BGP is to use community string in AA:NN format (e.g. 100:300). For the adverting routers (typically on customer edge), use "set community" in place of "set tag" in the route-map statement. For the recieving routers (typically on provider edge), use "ip community-list" to describe the community string and "match community". For further example on using BGP community, see this Cisco example.
Friday, March 25, 2011
Once you have uploaded the new image and before you reload the router, run this command:
#verify /md5 ‹ ios image location ›
example: verify /md5 flash:c1841-adventerprisek9-mz.124-25e.bin
Compare the output value with the MD5 sum that you noted earlier.
Wednesday, March 23, 2011
To enable netflow on the managed node:
Choose a netflow version (either 5 or 9) depending on your netflow console support. Solarwinds supports both versions
(config)# ip flow-export version 9
Send the netflow traffic to your netflow server's IP address and designated port no. VRF is optional but we use it for Out-of-band monitoring(config)# ip flow-export destination 10.10.10.10 1055 vrf vrf-name
Choose an interface that should report to the netflow server(config)# ip flow-export source interface-name
On the interfaces that you want to monitor. Add these commands at the interface level.(config-if)# ip flow ingress
(config-if)# ip flow egress
The above example is to monitor all traffic entering and leaving the interface. If you wish to monitor a specific flow, you can replace the above with Cisco Flexible Netflow (click on example). For Juniper J-flow configuration, refer to this example.
Monday, March 14, 2011
To rebuild the perfmon WMI, enter the following command using elevated command prompt at the system32 prompt:
C:\Windows\system32 > lodctr /R
Re-sync the perfmon counter with WMI by running winmgmt /resyncperf.
C:\Windows\system32 > winmgmt /resyncperf
And then restart the WMI service. The parameter 'R' for lodctr must be in capital for the rebuild. This parameter is not even documented on Microsoft Technet.
In the event of corruption of the Microsoft Windows registry, system files, or the System Center Data Protection Manager (DPM) 2010 binaries, you can repair DPM by reinstalling it. Repairing DPM involves backing up existing DPM database (using DPMBackup.exe -db cmd), uninstalling DPM, reinstalling DPM and then restoring the database. See this technet article for step-by-step.
Friday, March 4, 2011
"I realize that the news that it’s okay to have duplicate machine SIDs comes as a surprise to many, especially since changing SIDs on imaged systems has been a fundamental principle of image deployment since Windows NT’s inception. This blog post debunks the myth with facts by first describing the machine SID, explaining how Windows uses SIDs, and then showing that - with one exception - Windows never exposes a machine SID outside its computer, proving that it’s okay to have systems with the same machine SID."
Nevertheless, the blog concluded that sysprep is still necessary for Microsoft's support:
"Note that Sysprep resets other machine-specific state that, if duplicated, can cause problems for certain applications like Windows Server Update Services (WSUS), so Microsoft’s support policy will still require cloned systems to be made unique with Sysprep"
I would take this with a pinch of salt, as I did experience strange problems in the past for having duplicated SIDs. Or rather, I would interpret the statement this way - even though SID duplication per-se may not cause problems, unpredictable outcomes may still occur, as other machine-specific states are not reset. SID duplication is an indicator of such happening.