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
Thursday, January 07, 2010
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
Subscribe to:
Posts (Atom)