Friends,
Its been a long time since i blogged. Blame it entirely on me. I apologise (once again).
I am now at a cross roads in life where its time for me to decide whether I really want to pursue CCIE !
I have tired three times with full steam ahead and have fallen short of labbing even once. Forget passing or failing.
Blame it on lot of circumstances, all of them which I could control but didn't..
Work has never been a problem with me, my manager and everyone else at work & home supports me for the lab. I have world's best of facilities including a free air ticket, visa, hotel accommodation and 3 free LAB attempts....
Personal life has had its UPs not many downs....I am now a father of 2 children and am required to pay more attention to them....
I have had no issues finding time to study....Its the perennial disease which has stalled my career for last 5 years......PROCRASTINATION....I for some screwed up reason love to procrastinate....a lot of it.
I also realise I have slipped into comfort zone at work and at home.. Nothing anymore excites me to run at it and grab it....I don't know how to shrug off this comfort.
Its been a long cherished dream to have a CCIE, a dream now for over 10years. I still dream about CCIE, but fall miserably short of putting it into action for sustaining it till end of the preparation and into the lab.
I need your earnest advice,
DO I lab or let it go... ?
Monday, May 31, 2010
Friday, February 19, 2010
HSBC India: Power Vantage Account and still pay for Debit Card usage !
Well I was charged INR 160 (INR 150 for annual Debit Card usage) + Taxes by HSBC India.
This is despite I holding a Power Vantage Account with HSBC India for last 5 Years.
PowerVantage account means i need to maintain avg quarterly balance of minimum INR 1Lakh and yet they charge me for basic service like debit card usage !
How pathetic can HSBC get.
I hope you all realize that all the gloss and glamor that HSBC is useless and at the end they are after your money.
I bet if I ever went to HDFC or ICICI or any other Indian Bank they would never charge me for Debit Card Usage.
Honestly I will reassess my relationship with fucked up HSBC and soon plan to move my funds over to HDFC or other Indian Bank.
So much for the loyalty of 5 years of banking with HSBC.
This is despite I holding a Power Vantage Account with HSBC India for last 5 Years.
PowerVantage account means i need to maintain avg quarterly balance of minimum INR 1Lakh and yet they charge me for basic service like debit card usage !
How pathetic can HSBC get.
I hope you all realize that all the gloss and glamor that HSBC is useless and at the end they are after your money.
I bet if I ever went to HDFC or ICICI or any other Indian Bank they would never charge me for Debit Card Usage.
Honestly I will reassess my relationship with fucked up HSBC and soon plan to move my funds over to HDFC or other Indian Bank.
So much for the loyalty of 5 years of banking with HSBC.
Thursday, January 21, 2010
BGP:Fast Peering Session Deactivation
Trackback
The BGP Support for Fast Peering Session Deactivation feature introduces an event driven notification system that allows a Border Gateway Protocol (BGP) process to monitor BGP peering sessions on a per-neighbor basis. This feature improves the response time of BGP to adjacency changes by allowing BGP to detect an adjacency change and deactivate the terminated session in between standard BGP scanning intervals. Enabling this feature improves overall BGP convergence.
The BGP Support for Fast Peering Session Deactivation feature introduces an event driven notification system that allows a Border Gateway Protocol (BGP) process to monitor BGP peering sessions on a per-neighbor basis. This feature improves the response time of BGP to adjacency changes by allowing BGP to detect an adjacency change and deactivate the terminated session in between standard BGP scanning intervals. Enabling this feature improves overall BGP convergence.
Restrictions for BGP Support for Fast Peering Session Deactivation
•
•
neighbor 10.0.0.1 fall-over
Wednesday, January 20, 2010
MPLS: Change MTU - - The MPLS MTU to support Jumbo frames
PE1#sh mpls forwarding-table de
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or VC or Tunnel Id Switched interface
16 Pop Label 10.1.1.2/32 0 Fa0/0.21 172.16.12.2
MAC/Encaps=18/18, MRU=1504, Label Stack{} --> Default
CA040FE80008CA030FE80008810000158847
No output feature configured
PE1(config-if)#mtu 9216
% Interface FastEthernet0/0 does not support user settable mtu.
PE1(config-if)#mpls mtu ?
<1501-1524> MTU (baby giants bytes)
<64-1500> MTU (bytes)
PE1(config-if)#mpls mtu 1524
PE1#sh mpls forwarding-table de
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or VC or Tunnel Id Switched interface
16 Pop Label 10.1.1.2/32 0 Fa0/0.21 172.16.12.2
MAC/Encaps=18/18, MRU=1504, Label Stack{} --> Default, Stll no change ? Why
CA040FE80008CA030FE80008810000158847
No output feature configured
Now lets change it on subinterface
PE1(config)#int f0/0.31
PE1(config-subif)#mpls mtu 1524
PE1(config-subif)#^Z
PE1#
00:55:38: %SYS-5-CONFIG_I: Configured from console by console
PE1#sh mpls forwarding-table de
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or VC or Tunnel Id Switched interface
16 Pop Label 10.1.1.2/32 0 Fa0/0.21 172.16.12.2
MAC/Encaps=18/18, MRU=1528, Label Stack{} -->Changes show up,
CA040FE80008CA030FE80008810000158847
No output feature configured
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or VC or Tunnel Id Switched interface
16 Pop Label 10.1.1.2/32 0 Fa0/0.21 172.16.12.2
MAC/Encaps=18/18, MRU=1504, Label Stack{} --> Default
CA040FE80008CA030FE80008810000158847
No output feature configured
PE1(config-if)#mtu 9216
% Interface FastEthernet0/0 does not support user settable mtu.
PE1(config-if)#mpls mtu ?
<1501-1524> MTU (baby giants bytes)
<64-1500> MTU (bytes)
PE1(config-if)#mpls mtu 1524
PE1#sh mpls forwarding-table de
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or VC or Tunnel Id Switched interface
16 Pop Label 10.1.1.2/32 0 Fa0/0.21 172.16.12.2
MAC/Encaps=18/18, MRU=1504, Label Stack{} --> Default, Stll no change ? Why
CA040FE80008CA030FE80008810000158847
No output feature configured
Now lets change it on subinterface
PE1(config)#int f0/0.31
PE1(config-subif)#mpls mtu 1524
PE1(config-subif)#^Z
PE1#
00:55:38: %SYS-5-CONFIG_I: Configured from console by console
PE1#sh mpls forwarding-table de
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or VC or Tunnel Id Switched interface
16 Pop Label 10.1.1.2/32 0 Fa0/0.21 172.16.12.2
MAC/Encaps=18/18, MRU=1528, Label Stack{} -->Changes show up,
CA040FE80008CA030FE80008810000158847
No output feature configured
MPSL: LDP backoff
PE1#sh mpls ldp parameters
Protocol version: 1
Session hold time: 180 sec; keep alive interval: 60 sec
Discovery hello: holdtime: 15 sec; interval: 5 sec
Discovery targeted hello: holdtime: 90 sec; interval: 10 sec
Downstream on Demand max hop count: 4
LDP for targeted sessions
LDP initial/maximum backoff: 15/120 sec -->Defaults
LDP loop detection: off
PE1
PE1(config)#mpls ldp backoff 60 240
PE1#sh mpls ldp parameters
Protocol version: 1
Session hold time: 180 sec; keep alive interval: 60 sec
Discovery hello: holdtime: 15 sec; interval: 5 sec
Discovery targeted hello: holdtime: 90 sec; interval: 10 sec
Downstream on Demand max hop count: 4
LDP for targeted sessions
LDP initial/maximum backoff: 60/240 sec -->Modified
LDP loop detection: off
PE1#
Protocol version: 1
Session hold time: 180 sec; keep alive interval: 60 sec
Discovery hello: holdtime: 15 sec; interval: 5 sec
Discovery targeted hello: holdtime: 90 sec; interval: 10 sec
Downstream on Demand max hop count: 4
LDP for targeted sessions
LDP initial/maximum backoff: 15/120 sec -->Defaults
LDP loop detection: off
PE1
PE1(config)#mpls ldp backoff 60 240
PE1#sh mpls ldp parameters
Protocol version: 1
Session hold time: 180 sec; keep alive interval: 60 sec
Discovery hello: holdtime: 15 sec; interval: 5 sec
Discovery targeted hello: holdtime: 90 sec; interval: 10 sec
Downstream on Demand max hop count: 4
LDP for targeted sessions
LDP initial/maximum backoff: 60/240 sec -->Modified
LDP loop detection: off
PE1#
MPLS: Maximum Hop count for Lable Bindings dont exceed x hops
global
mpls ldp maxhops 4
PE1#sh mpls ldp parameters
Protocol version: 1
Session hold time: 180 sec; keep alive interval: 60 sec
Discovery hello: holdtime: 15 sec; interval: 5 sec
Discovery targeted hello: holdtime: 90 sec; interval: 10 sec
Downstream on Demand max hop count: 4
LDP for targeted sessions
LDP initial/maximum backoff: 15/120 sec
LDP loop detection: off
PE1#
mpls ldp maxhops 4
PE1#sh mpls ldp parameters
Protocol version: 1
Session hold time: 180 sec; keep alive interval: 60 sec
Discovery hello: holdtime: 15 sec; interval: 5 sec
Discovery targeted hello: holdtime: 90 sec; interval: 10 sec
Downstream on Demand max hop count: 4
LDP for targeted sessions
LDP initial/maximum backoff: 15/120 sec
LDP loop detection: off
PE1#
ISIS:Have loop free path: Somewhat convoluted: But means have only one path
Have loop free path ==> (Somewhat convoluted:) But means have only one path
router isis
maximum-paths 1
router isis
maximum-paths 1
Thursday, January 14, 2010
BGP: Load Balancing over BGP
Trackback
As per the config guide there are various ways BGP can load Balance over two links
1) Use IGP between two neighbors and peer using loopbacks. Have IGP load balance the peer's next-hop-ip.
2) Use maximum-path router cmd to have BGP install more than 1 route in routing table.
As per the config guide there are various ways BGP can load Balance over two links
1) Use IGP between two neighbors and peer using loopbacks. Have IGP load balance the peer's next-hop-ip.
2) Use maximum-path router cmd to have BGP install more than 1 route in routing table.
Wednesday, January 13, 2010
Multicast: DVMRP
How to locate in DocCD ?
Configuration Guide -->Cisco IOS IP Multicast Configuration Guide, Release 12.4T-->Configuring DVMRP Interoperability
Two things to remember
1) Create a Tunnel from Router to the Unix host, use source int = directly connected int = fasx/x
tunnel dest = unix server IP
2) Advertise the directly connected subnet ( or for that matter any subnet) via ACL and this cmd
ip dvmrp metric 2 list 10
10 = ACL for the subnet to be adv
2 = metric
Configuration Guide -->Cisco IOS IP Multicast Configuration Guide, Release 12.4T-->Configuring DVMRP Interoperability
Two things to remember
1) Create a Tunnel from Router to the Unix host, use source int = directly connected int = fasx/x
tunnel dest = unix server IP
2) Advertise the directly connected subnet ( or for that matter any subnet) via ACL and this cmd
ip dvmrp metric 2 list 10
10 = ACL for the subnet to be adv
2 = metric
Multicast: ip multicast ttl-threshold x
Trackback
Some references in Blogs here
basically, the TTL of packet received should be higher than the TTL threshold configured
So if the config is as follows
PE3(config)#int f0/0.13
PE3(config-subif)#ip mul
PE3(config-subif)#ip multicast tt
PE3(config-subif)#ip multicast ttl-threshold 9
PE3(config-subif)#
Then any incoming multicast packet with TTL=10 or greater will be forwarded.
Any incoming multicast packet with TTL=9 or lesser will be discarded.
Some references in Blogs here
basically, the TTL of packet received should be higher than the TTL threshold configured
So if the config is as follows
PE3(config)#int f0/0.13
PE3(config-subif)#ip mul
PE3(config-subif)#ip multicast tt
PE3(config-subif)#ip multicast ttl-threshold 9
PE3(config-subif)#
Then any incoming multicast packet with TTL=10 or greater will be forwarded.
Any incoming multicast packet with TTL=9 or lesser will be discarded.
Multicast: Rate Limit Multicast Traffic
Nice GroupStudy Observation
Some references in the blog here and here
PE1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
PE1(config)#int f0/0.21
PE1(config-subif)#ip multicast rate-limit out 200
PE1(config-subif)#^Z
PE1#
5d20h: %SYS-5-CONFIG_I: Configured from console by console
PE1#sh ip mro
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.0.1.39), 01:45:58/stopped, RP 0.0.0.0, flags: DC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/0.31, Forward/Sparse-Dense, 01:45:58/00:00:00
FastEthernet0/0.21, Forward/Sparse-Dense, 01:45:58/00:00:00, Int limit 200 kbps
(10.1.1.1, 224.0.1.39), 01:45:10/00:02:49, flags: T
Incoming interface: Loopback0, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/0.21, Forward/Sparse-Dense, 01:45:10/00:00:00, Int limit 200 kbps
FastEthernet0/0.31, Forward/Sparse-Dense, 01:45:10/00:00:00
Some references in the blog here and here
PE1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
PE1(config)#int f0/0.21
PE1(config-subif)#ip multicast rate-limit out 200
PE1(config-subif)#^Z
PE1#
5d20h: %SYS-5-CONFIG_I: Configured from console by console
PE1#sh ip mro
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.0.1.39), 01:45:58/stopped, RP 0.0.0.0, flags: DC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/0.31, Forward/Sparse-Dense, 01:45:58/00:00:00
FastEthernet0/0.21, Forward/Sparse-Dense, 01:45:58/00:00:00, Int limit 200 kbps
(10.1.1.1, 224.0.1.39), 01:45:10/00:02:49, flags: T
Incoming interface: Loopback0, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/0.21, Forward/Sparse-Dense, 01:45:10/00:00:00, Int limit 200 kbps
FastEthernet0/0.31, Forward/Sparse-Dense, 01:45:10/00:00:00
Multicast: ip pim accept-register list
SSM : Source Specific Multicast
=> Allow only certain sources to register with RP.
Trackback
Merge this with the allowing access only to Even Multicast Group via modifying this ACL
and you get following.
ip access-list extended SSM
deny ip host 10.23.1.1 229.0.0.1 0.0.0.254
permit ip any any
ip pim accept-register list SSM
This way 10.23.1.1 will not be able to register with RP for odd groups in 229.0.0.x multicast groups. Rest (even and anything else) is allowed
=> Allow only certain sources to register with RP.
Trackback
Merge this with the allowing access only to Even Multicast Group via modifying this ACL
and you get following.
ip access-list extended SSM
deny ip host 10.23.1.1 229.0.0.1 0.0.0.254
permit ip any any
ip pim accept-register list SSM
This way 10.23.1.1 will not be able to register with RP for odd groups in 229.0.0.x multicast groups. Rest (even and anything else) is allowed
Tuesday, January 12, 2010
Multicast: ip pim neighbor-filter : Stub Multicast Routing:
Stub Multicast Routing
Why ?
1) Save Upstream Router's Resources as the downstream Router doesnt participate in PIM anymore.....
2) Save RP's Resources as the downstream Router doesnt participate in PIM anymore.....
3) Security: Downstream Router now unaware of your RPs, Cannot advertise his groups to RP.
4) Security: Downstream Router cannot be the DR as well, since DR is elected via PIM. So you control who becomes the DR on a broadcast segment.
How ?
Receivers<--(f0/1)CE8 (f0/0)--(f0/0.82)PE2-->RP
PE2#sh run int f0/0.82
Building configuration...
Current configuration : 148 bytes
!
interface FastEthernet0/0.82
encapsulation dot1Q 82
ip address 10.82.1.2 255.255.255.0
ip pim neighbor-filter 3
ip pim sparse-dense-mode
end
PE2#
PE2#sh access-l 3
Standard IP access list 3
10 deny 10.82.1.1 (89 matches) --> This is the IP address of the CE8 interface f0/0
20 permit any
PE2#
By filtering off CE8, we no more have PIM neighborship with him on interface f0/0.82
Now CE8 cannot communicate with the Upstream Multicast Senders.
To enable this we have to conf following on CE8 where receivers are located ( int f0/1)
CE8 now communicates with PE2 via PIM Dense mode.
All traffic in CE8 is dense.
CE8#sh run int f0/1
Building configuration...
Current configuration : 349 bytes
!
interface FastEthernet0/1
ip igmp helper-address 10.82.1.2
CE8#
Why ?
1) Save Upstream Router's Resources as the downstream Router doesnt participate in PIM anymore.....
2) Save RP's Resources as the downstream Router doesnt participate in PIM anymore.....
3) Security: Downstream Router now unaware of your RPs, Cannot advertise his groups to RP.
4) Security: Downstream Router cannot be the DR as well, since DR is elected via PIM. So you control who becomes the DR on a broadcast segment.
How ?
Receivers<--(f0/1)CE8 (f0/0)--(f0/0.82)PE2-->RP
PE2#sh run int f0/0.82
Building configuration...
Current configuration : 148 bytes
!
interface FastEthernet0/0.82
encapsulation dot1Q 82
ip address 10.82.1.2 255.255.255.0
ip pim neighbor-filter 3
ip pim sparse-dense-mode
end
PE2#
PE2#sh access-l 3
Standard IP access list 3
10 deny 10.82.1.1 (89 matches) --> This is the IP address of the CE8 interface f0/0
20 permit any
PE2#
By filtering off CE8, we no more have PIM neighborship with him on interface f0/0.82
Now CE8 cannot communicate with the Upstream Multicast Senders.
To enable this we have to conf following on CE8 where receivers are located ( int f0/1)
CE8 now communicates with PE2 via PIM Dense mode.
All traffic in CE8 is dense.
CE8#sh run int f0/1
Building configuration...
Current configuration : 349 bytes
!
interface FastEthernet0/1
ip igmp helper-address 10.82.1.2
CE8#
Multicast: sh ip pim rp output
Sh ip pim rp output
PE3#sh ip pim rp
Group: 235.235.235.235, RP: 10.1.1.3, v2, v1, next RP-reachable in 00:00:28
Group: 224.2.2.2, RP: 10.1.1.3, next RP-reachable in 00:00:34
Group: 225.2.2.2, RP: 10.1.1.3, v2, v1, next RP-reachable in 00:01:28
PE3#
the ones with v2,v1,next RP-reachable are the entries for which we are the RP.
But to tell if this was via static or Auto-RP, we have to do sh ip pim rp mappings
PE3#sh ip pim rp ma
PIM Group-to-RP Mappings
This system is an RP (Auto-RP)
Group(s) 225.2.2.2/32
RP 10.1.1.3 (?), v2v1
Info source: 10.1.1.2 (?), elected via Auto-RP
Uptime: 00:11:30, expires: 00:02:26
Group(s) 225.8.8.8/32
RP 10.1.1.2 (?), v2v1
Info source: 10.1.1.2 (?), elected via Auto-RP
Uptime: 00:15:24, expires: 00:02:26
Group(s) 229.0.0.1/32
RP 10.1.1.2 (?), v2v1
Info source: 10.1.1.2 (?), elected via Auto-RP
Uptime: 00:15:24, expires: 00:02:26
Group(s) 235.0.0.0/8
RP 10.1.1.3 (?), v2v1
Info source: 10.1.1.2 (?), elected via Auto-RP
Uptime: 00:06:30, expires: 00:02:27
Acl: 1, Static
RP: 10.1.1.3 (?)
PE3#
PE3#sh access-l 1
Standard IP access list 1
10 permit 224.2.2.2 (39514 matches)
PE3#
PE3#sh ip pim rp
Group: 235.235.235.235, RP: 10.1.1.3, v2, v1, next RP-reachable in 00:00:28
Group: 224.2.2.2, RP: 10.1.1.3, next RP-reachable in 00:00:34
Group: 225.2.2.2, RP: 10.1.1.3, v2, v1, next RP-reachable in 00:01:28
PE3#
the ones with v2,v1,next RP-reachable are the entries for which we are the RP.
But to tell if this was via static or Auto-RP, we have to do sh ip pim rp mappings
PE3#sh ip pim rp ma
PIM Group-to-RP Mappings
This system is an RP (Auto-RP)
Group(s) 225.2.2.2/32
RP 10.1.1.3 (?), v2v1
Info source: 10.1.1.2 (?), elected via Auto-RP
Uptime: 00:11:30, expires: 00:02:26
Group(s) 225.8.8.8/32
RP 10.1.1.2 (?), v2v1
Info source: 10.1.1.2 (?), elected via Auto-RP
Uptime: 00:15:24, expires: 00:02:26
Group(s) 229.0.0.1/32
RP 10.1.1.2 (?), v2v1
Info source: 10.1.1.2 (?), elected via Auto-RP
Uptime: 00:15:24, expires: 00:02:26
Group(s) 235.0.0.0/8
RP 10.1.1.3 (?), v2v1
Info source: 10.1.1.2 (?), elected via Auto-RP
Uptime: 00:06:30, expires: 00:02:27
Acl: 1, Static
RP: 10.1.1.3 (?)
PE3#
PE3#sh access-l 1
Standard IP access list 1
10 permit 224.2.2.2 (39514 matches)
PE3#
Thursday, January 07, 2010
Multicast: ip pim query-interval and ip igmp query-inerval
ip igmp query-interval is used to query the reports to find out if any receivers are still active on the LAN segment
ip pim query-interval is used to send PIM Hello updates
ip pim query-interval is used to send PIM Hello updates
Multicast: Hosts that dont support IGMP
If there are hosts that dont support IGMP on a LAN Segment.
The router connecting that LAN segment can join IGMP group statically on their behalf
int f0/0
ip igmp static-group 235.1.1.1
Here if we ran a ping 235.1.1.1 from the source, the Router will not respond only the receivers ( End Hosts) will respond.
Whereas in the igmp join-group, even the router's interface responds.
Also (*,G) entry for join-group will have flags C (Connected) & L(Local)
The static-group will have flags C (Connected) only..
The router connecting that LAN segment can join IGMP group statically on their behalf
int f0/0
ip igmp static-group 235.1.1.1
Here if we ran a ping 235.1.1.1 from the source, the Router will not respond only the receivers ( End Hosts) will respond.
Whereas in the igmp join-group, even the router's interface responds.
Also (*,G) entry for join-group will have flags C (Connected) & L(Local)
The static-group will have flags C (Connected) only..
using Overload Bit to avoid BGP black hole when router reboots
From RFC3787
4. Overload Bit
To deal with transient problems that prevent an IS from storing all
the LSPs it receives, ISO 10589 defines an LSP Database Overload
condition in section 7.3.19. When an IS is in Database Overload
condition, it sets a flag called the Overload Bit in the non-
pseudonode LSP number Zero that it generates. Section 7.2.8.1 of ISO
10589 instructs other systems not to use the overloaded IS as a
transit router. Since the overloaded IS does not have complete
information, it may not be able to compute the right routes, and
routing loops could develop. However, an overloaded router may be
used to reach End Systems directly attached to the router, as it may
provide the only path to an End System.
The ability to signal reduced knowledge is so useful that the meaning
of this flag has been overloaded. In a Service Provider's network,
when a router running BGP and IS-IS reboots, BGP might take more time
to converge than IS-IS. Thus the router may drop traffic for
destinations not yet learned via BGP. It is convenient to set the
Overload Bit until BGP has converged, as described in "Intermediate
System to Intermediate System (IS-IS) Transient Blackhole Avoidance"
[6].
An implementation SHOULD use the Overload Bit to signal that it is
not ready to accept transit traffic.
router isis
set-overload-bit on-startup wait-for-bgp
ISIS: hello-interval and hello-multiplier
int s2/0
isis hello-interval x level-2
isis hello-multiplier 3
Defaults
hello-interval is 10s
hello-multiplier is 3
hello-hold interval is 10s x 3 = 30s
isis hello-interval x level-2
isis hello-multiplier 3
Defaults
hello-interval is 10s
hello-multiplier is 3
hello-hold interval is 10s x 3 = 30s
ISIS: max-lsp-lifetime & lsp-refresh-interval
How to find it on Doc CD
Some one pls help me navigate it. The above link i found via google
Some one pls help me navigate it. The above link i found via google
Related Commands
Command | Description |
|---|---|
Sets the maximum time that link-state packets (LSPs) can remain in a router's database without being refreshed. |
max-lsp-lifetime (IS-IS)
To set the maximum time that link-state packets (LSPs) can remain in a router's database without being refreshed, use the max-lsp-lifetime command in router configuration mode. To restore the default lifetime, use the no form of this command.
max-lsp-lifetime seconds
no max-lsp-lifetime
Syntax Description
seconds | Lifetime of the LSP in seconds. The range is 1 to 65535 seconds; the default is 1200 seconds (20 minutes). |
Defaults
1200 seconds (20 minutes)
Command Modes
Router configuration
Command History
Usage Guidelines
If the lifetime is exceeded before a refresh LSP arrives, the LSP is dropped from the database.
You might need to adjust the maximum LSP lifetime if you change the LSP refresh interval with the lsp-refresh-interval (IP) command. LSPs must be periodically refreshed before their lifetimes expire. The value set for the lsp-refresh-interval command should be less than the value set for the max-lsp-lifetime command; otherwise, LSPs will time out before they are refreshed. If you misconfigure the LSP lifetime to be too low compared to the LSP refresh interval, the software will reduce the LSP refresh interval to prevent the LSPs from timing out.
You might prefer higher values for each command in order to reduce control traffic, at the expense of holding stale LSPs from a crashed or unreachable router in the database longer (thus wasting memory) or increasing the risk of undetected bad LSPs staying active (very rare).
Examples
The following example configures an LSP lifetime of 40 minutes:
router isis
max-lsp-lifetime 2400
Related Commands
lsp-refresh-interval (IS-IS)
To set the link-state packet (LSP) refresh interval, use the lsp-refresh-interval command in router configuration mode. To restore the default refresh interval, use the no form of this command.
lsp-refresh-interval seconds
no lsp-refresh-interval
Syntax Description
seconds | Interval (in seconds) at which LSPs are refreshed.The range is 1 to 65535 seconds. The default value is 900 seconds (15 minutes). |
Defaults
900 seconds (15 minutes)
Command Modes
Router configuration
Command History
Usage Guidelines
The refresh interval determines the rate at which Cisco IOS software periodically transmits in LSPs the route topology information that it originates. This is done to keep the database information from becoming too old.
LSPs must be periodically refreshed before their lifetimes expire. The value set for the lsp-refresh-interval command should be less than the value set for the max-lsp-lifetime command; otherwise, LSPs will time out before they are refreshed. If you misconfigure the LSP lifetime to be too low compared to the LSP refresh interval, the software will reduce the LSP refresh interval to prevent the LSPs from timing out.
Reducing the refresh interval reduces the amount of time that undetected link state database corruption can persist at the cost of increased link utilization. (This is an extremely unlikely event, however, because there are other safeguards against corruption.) Increasing the interval reduces the link utilization caused by the flooding of refreshed packets (although this utilization is very small).
Examples
The following example configures the IS-IS LSP refresh interval to be 1080 seconds (18 minutes):
router isis
lsp-refresh-interval 1080
Related Commands
Command | Description |
|---|---|
Sets the maximum time that link-state packets (LSPs) can remain in a router's database without being refreshed. |
max-lsp-lifetime (IS-IS)
To set the maximum time that link-state packets (LSPs) can remain in a router's database without being refreshed, use the max-lsp-lifetime command in router configuration mode. To restore the default lifetime, use the no form of this command.
max-lsp-lifetime seconds
no max-lsp-lifetime
Syntax Description
seconds | Lifetime of the LSP in seconds. The range is 1 to 65535 seconds; the default is 1200 seconds (20 minutes). |
Defaults
1200 seconds (20 minutes)
Command Modes
Router configuration
Command History
Usage Guidelines
If the lifetime is exceeded before a refresh LSP arrives, the LSP is dropped from the database.
You might need to adjust the maximum LSP lifetime if you change the LSP refresh interval with the lsp-refresh-interval (IP) command. LSPs must be periodically refreshed before their lifetimes expire. The value set for the lsp-refresh-interval command should be less than the value set for the max-lsp-lifetime command; otherwise, LSPs will time out before they are refreshed. If you misconfigure the LSP lifetime to be too low compared to the LSP refresh interval, the software will reduce the LSP refresh interval to prevent the LSPs from timing out.
You might prefer higher values for each command in order to reduce control traffic, at the expense of holding stale LSPs from a crashed or unreachable router in the database longer (thus wasting memory) or increasing the risk of undetected bad LSPs staying active (very rare).
Examples
The following example configures an LSP lifetime of 40 minutes:
router isis
max-lsp-lifetime 2400
ISIS: Jumbo Frames enabling causes high CPU Load !
Back in this post we mentioned how changing mtu causes ISIS neighborship to go down.
This was remedied by have the same clns mtu on both peers.
However this might cause another problem.
Every 10secs hello are sent out to neighbors with frames of size of the clns mtu.
This is done by padding data onto the frames.
This is called hello padding.
To optimize CPU cycles we can disable Hello Padding.
Either using router level cmd or Interface level cmd
router isis
no hello padding multi-point
OR
int s2/0.1 multipoint
no isis hello padding
Also configure the peer
int s2/0
no isis hello padding
This was remedied by have the same clns mtu on both peers.
However this might cause another problem.
Every 10secs hello are sent out to neighbors with frames of size of the clns mtu.
This is done by padding data onto the frames.
This is called hello padding.
To optimize CPU cycles we can disable Hello Padding.
Either using router level cmd or Interface level cmd
router isis
no hello padding multi-point
OR
int s2/0.1 multipoint
no isis hello padding
Also configure the peer
int s2/0
no isis hello padding
ISIS: Redstribution between L1 and L2
router isis
redistribute isis ip level-2 into level-1 distribute-list 100
ip access-list extended 100
permit ip any any
The above must be done at ABR, This will allow all L2 routes to be seen in L1 as ia
redistribute isis ip level-2 into level-1 distribute-list 100
ip access-list extended 100
permit ip any any
The above must be done at ABR, This will allow all L2 routes to be seen in L1 as ia
ISIS: ip mtu different ! neighborship not formed !
If we have different mtu between two neighbors ISIS neighborship doesnt come up.
More here on CCO support forum.
However, while I was reading up for CCIE, I found a workaround.
if we leave the ip mtu to be different but change the clns mtu to match up, the ISIS neighborship comes up.
More here on CCO support forum.
However, while I was reading up for CCIE, I found a workaround.
if we leave the ip mtu to be different but change the clns mtu to match up, the ISIS neighborship comes up.
R1 s2/0 -- R2 s2/0
R1
int s2/0
mtu 17001
clns mtu 9216
R2
int s2/0
mtu 17008
clns mtu 9216
Back-to-Back FR
PE1
frame-relay switching
int s2/0
encap frame-relay
no frame-relay inverse-arp
no keepalive
ip add 1.1.1.1 255.255.255.0
frame-relay map ip 1.1.1.2 100 broadcast
no shut
ASBR1
frame-relay switching
int s2/2
encap frame-relay
no frame-relay inverse-arp
no keepalive
ip add 1.1.1.2 255.255.255.0
frame-relay map ip 1.1.1.1100 broadcast
no shut
The Point is for back to back FR
1) we must disable keepalives , else PVC shows DELETED
2) we must use same DLCI ( in our e.g 100) , else it doesnt work.
frame-relay switching
int s2/0
encap frame-relay
no frame-relay inverse-arp
no keepalive
ip add 1.1.1.1 255.255.255.0
frame-relay map ip 1.1.1.2 100 broadcast
no shut
ASBR1
frame-relay switching
int s2/2
encap frame-relay
no frame-relay inverse-arp
no keepalive
ip add 1.1.1.2 255.255.255.0
frame-relay map ip 1.1.1.1100 broadcast
no shut
The Point is for back to back FR
1) we must disable keepalives , else PVC shows DELETED
2) we must use same DLCI ( in our e.g 100) , else it doesnt work.
ISIS: Router level config takes precedence over Interface level config
Lets say i have this setup
ASBR1 s2/2 --> PE1 s2/0
I want to run ISIS on this interface at Level-2 only.
This wont work
ASBR1
router isis
is-type level-2
int s2/2
ip router isis
PE1
router isis
is-type level-1
int s2/0
ip router isis
isis circuit-type level-2
It seems that on PE1 the Router ISIS (is-type ) cmd takes precedence over int s2/0 ( isis circuit-type) cmd
Strange isn't it , but that ISIS for you.
Once I modified the is-type to level-1-2 ( the default) on PE1, the neighborship came up.
Conclusion: Router ISIS (is-type ) cmd takes precedence over int s2/0 ( isis circuit-type) cmd
ASBR1 s2/2 --> PE1 s2/0
I want to run ISIS on this interface at Level-2 only.
This wont work
ASBR1
router isis
is-type level-2
int s2/2
ip router isis
PE1
router isis
is-type level-1
int s2/0
ip router isis
isis circuit-type level-2
It seems that on PE1 the Router ISIS (is-type ) cmd takes precedence over int s2/0 ( isis circuit-type) cmd
Strange isn't it , but that ISIS for you.
Once I modified the is-type to level-1-2 ( the default) on PE1, the neighborship came up.
Conclusion: Router ISIS (is-type ) cmd takes precedence over int s2/0 ( isis circuit-type) cmd
Wednesday, January 06, 2010
OSPF : RFC 2328 / RFC 1583
The default for calculating summary route's cost is RFC 1583.
RFC 2328 uses a different method .
Cisco conforms to both but RFC 1583 is default.
So to use RFC 2328 instead
specify following
router ospf 1
no compatible rfc1583
RFC 2328 uses a different method .
Cisco conforms to both but RFC 1583 is default.
So to use RFC 2328 instead
specify following
router ospf 1
no compatible rfc1583
Reduce OSPF LSA Flooding v/s Prevent OSPF LSA Flooding.
Earlier I mentioned how to prevent LSA flooding using interface level cmd ip ospf database-filter all out.
Now supposedly, you want to reduce flooding instead of preventing it :-) (Symantecs of Stupid English)
you would apply this cmd
ip ospf flood-reduction
Now supposedly, you want to reduce flooding instead of preventing it :-) (Symantecs of Stupid English)
you would apply this cmd
ip ospf flood-reduction
Jumbo Frames and MTU and OSPF neighbor ship
The moment one changes mtu on ONLY one end of the link to support Jumbo Frames ( > 9000 bytes) , when OSPF is restarted it will fail to form adjacency since MTU mismatch will occur.
To ignore MTU mismatch, specify ip ospf mtu-ignore on both ends of the link.
To ignore MTU mismatch, specify ip ospf mtu-ignore on both ends of the link.
Prevent Flooding of OSPF LSA Broadcasts
Trackback
int s0/0.100
ip ospf database-filter all out
Will allow receiving Hello and LSA from peer
But wont sent out our LSA to them. Our Hellos are still sent out.
==> WE form adjacency with peer. WE get their LSA and install in our routing table
==>Peer forms adjacency with us. peer doesnt get our LSA and hence doesnt see our routes.
==> One way Traffic Flow.... Can be useful in Redundant links / FR Hub n Spoke Topology
The Biggest difference between passive-interface and database-filter is with passive-interface, even hellos are not sent out. So no adjacency and no one way communication.
int s0/0.100
ip ospf database-filter all out
Will allow receiving Hello and LSA from peer
But wont sent out our LSA to them. Our Hellos are still sent out.
==> WE form adjacency with peer. WE get their LSA and install in our routing table
==>Peer forms adjacency with us. peer doesnt get our LSA and hence doesnt see our routes.
==> One way Traffic Flow.... Can be useful in Redundant links / FR Hub n Spoke Topology
The Biggest difference between passive-interface and database-filter is with passive-interface, even hellos are not sent out. So no adjacency and no one way communication.
ignore lsa mospf ==> Do not generate syslog for Type 6 (MOSPF) packets
trackback
And also on CCO
Cisco routers do not support LSA Type 6 MOSPF packets, and they generate syslog messages if they receive such packets. If the router is receiving many MOSPF packets, you might want to configure the router to ignore the packets and thus prevent a large number of syslog messages.
Remember Type 6 LSA = MOSPF LSA
And also on CCO
Cisco routers do not support LSA Type 6 MOSPF packets, and they generate syslog messages if they receive such packets. If the router is receiving many MOSPF packets, you might want to configure the router to ignore the packets and thus prevent a large number of syslog messages.
Remember Type 6 LSA = MOSPF LSA
Quickest Convergence without using any L3 (OSPF) features
Trackback
carrier-delay msec 0
the default is 2sec for a link to signal failure.
With carrier-delay msec 0 , the change is signaled immediately for Routing protocols to take their course of action.
carrier-delay msec 0
the default is 2sec for a link to signal failure.
With carrier-delay msec 0 , the change is signaled immediately for Routing protocols to take their course of action.
OSPF LSA flooding pacing
The CCO link explains
ASBR1(config-router)#timers pacing ?
flood OSPF flood pacing timer
lsa-group OSPF LSA group pacing timer
retransmission OSPF retransmission pacing timer
ASBR1(config-router)#timers pacing ?
flood OSPF flood pacing timer
lsa-group OSPF LSA group pacing timer
retransmission OSPF retransmission pacing timer
Feature Overview
In rare situations, you might need to change Open Shortest Path First (OSPF) packet-pacing default timers to mitigate CPU or buffer utilization issues associated with flooding very large numbers of link-state advertisements (LSAs). The OSPF Update Packet-Pacing Configurable Timers feature allows you to configure the rate at which OSPF LSA flood pacing, retransmission pacing, and group pacing updates occur.
Configuring OSPF flood pacing timers allows you to control interpacket spacing between consecutive link-state update packets in the OSPF transmission queue. Configuring OSPF retransmission pacing timers allows you to control interpacket spacing between consecutive link-state update packets in the OSPF retransmission queue. Cisco IOS software groups the periodic refresh of LSAs to improve the LSA packing density for the refreshes in large topologies. The group timer controls the interval used for group LSA refreshment; however, this timer does not change the frequency that individual LSAs are refreshed (the default refresh occurs every 30 minutes).
The default are
LSA group pacing timer 240 secs ==> timers pacing lsa-group
Interface flood pacing timer 33 msecs ==> timers pacing flood
Retransmission pacing timer 66 msecs ==> timers pacing retransmission
OSPF : Configure with Highest Level Security !
=> Must use md5 authentication instead of the three types available ( null, normal,md5)
i.e
router ospf 1
area 0 authentication message-digest
int f0/0
ip ospf message-digest 1 md5 CISCO
OR
int f0/0
ip ospf authentication message-digest
ip ospf message-digest 1 md5 CISCO
i.e
router ospf 1
area 0 authentication message-digest
int f0/0
ip ospf message-digest 1 md5 CISCO
OR
int f0/0
ip ospf authentication message-digest
ip ospf message-digest 1 md5 CISCO
Saturday, January 02, 2010
BGP Features
Rack1R3#sh run | b r bgp
router bgp 500
neighbor 192.10.1.254 maximum-prefix 7500 100 restart 15
!
Rack1R3#sh ip bgp neighbor 192.10.1.254 | in (Max|Thres)
Maximum prefixes allowed 7500
Threshold for warning message 100%, restart interval 15 min
Rack1R3#
router bgp 500
neighbor 192.10.1.254 maximum-prefix 7500 100 restart 15
!
Rack1R3#sh ip bgp neighbor 192.10.1.254 | in (Max|Thres)
Maximum prefixes allowed 7500
Threshold for warning message 100%, restart interval 15 min
Rack1R3#
Subscribe to:
Posts (Atom)