Hello timer behaviors

Interior gateway routing protocols (IGPs) have varying intervals at which they send hello packets to neighbors. Ideally, neighbors should have matching hello and hold intervals, but some protocols will allow neighbors with mismatched timers to form an adjacency. Assume a lab of two routers, Router1 and Router2, directly connected via their Fa0/0 interfaces and addressed in the 192.168.0.0/30 subnet.

EIGRP

By default, EIGRP sends hellos every 5 seconds on LAN interfaces and every 60 seconds on WAN interfaces; the hold timer is three times the hello timer (15 or 180 seconds, respectively). We can adjust the hello interval per interface with:
Router(config-if)# ip hello-interval eigrp 
After configuring Router1 with a hello interval of 10 seconds, and leaving Router2 at its default setting of 5 seconds, we can issue the show ip eigrp neighbors command to observe that an adjacency is still successfully formed:
Router2# show ip eigrp neighbors
IP-EIGRP neighbors for process 100
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                        (sec)         (ms)       Cnt Num

0   192.168.0.2             Fa0/0              8 00:05:54   40   240  0  2
However, remember that Router2's dead interval is 15 seconds (three times its hello interval). If we were to raise Router1's hello interval above Router2's dead interval, Router2 would not receive hello packets soon enough and would declare the adjacency down after fifteen seconds.
Read on to see how OSPF and IS-IS neighbors handle mismatched timers.

OSPF

By default, OSPF uses a 10-second hello timer and 40-second hold timer on broadcast and point-to-point links, and a 30-second hello timer and 120-second hold timer for all other network types. An interface's hello timer can be adjusted:
Router(config-if)# ip ospf hello-interval 
If we set Router1 to use a hello timer of 15 seconds and leave Router2 at its default setting of 10 seconds, they will not form an adjacency. Note that this behavior is different from EIGRP. If we enable OSPF hello packet debugging with debug ip ospf hello, the router reports mismatched hello parameters (specifically the hello and dead intervals):
OSPF: Rcv hello from 192.168.0.2 area 0 from FastEthernet0/0 192.168.0.2
OSPF: Mismatched hello parameters from 192.168.0.2
OSPF: Dead R 40 C 60, Hello R 10 C 15  Mask R 255.255.255.252 C 255.255.255.252

IS-IS

By default, IS-IS uses a 10-second hello interval and 30-second dead interval, with the exception of a broadcast segment's designated router, which sends hellos at one-third the normal interval (every 3.3 seconds). We can adjust the hello interval on an interface with:
Router(config-if)# isis hello-interval  [level-1 | level-2]
To minimize confusion regarding the special-case DR timer mentioned, assume the link between the two peers has been configured as point-to-point (isis network point-to-point is applied to both interfaces). After configuring Router1 with a hello timer of 15 seconds and leaving Router2 at its default of 10 seconds, we see that the adjacency successfully forms similar to EIGRP.
Router2# show isis neighbors detail

System Id      Type Interface IP Address      State Holdtime Circuit Id
Router1        L1L2 Fa0/0     192.168.0.1     UP    37       00
  Area Address(es): 49.0001
  SNPA: c200.6876.0000      
  State Changed: 00:02:58
  Format: Phase V
Router1 has a hold timer of 45 seconds (three times 15 seconds) and Router2 has a hold timer of 30 seconds (three times 10 seconds). Thus, if Router2 misses two hellos from Router1 (spanning a total of 30 seconds), it will declare the adjacency dead before Router1.

Summary

Our experiments have shown that neighbors with mismatched hello timers will happily form adjacencies under EIGRP and IS-IS, but not OSPF. While one could argue this is a drawback of OSPF, I view it as a sanity-checking feature. Adjacencies between peers with timers configured too far apart will drop at what seem to be random intervals, which can make troubleshooting a nightmare. For this reason, peers should always be configured with matching timers.

Source : http://packetlife.net/

Access-lists vs Prefix-lists

The main purpose of this post is to show how prefix lists work and how to decipher them vs regular access lists.  Access-lists do a great job on Cisco devices, not just for security but all kinds of route filtering,  QoS and so on.
A prefix list is a bit different form an access-list, and it’s important to know the differences and when to use either.
I’ve created the following simple topology to illustrate what I’m going to be doing. There are 2 routers, both running BGP. Router1 will have numerous loopbacks with IP addresses that will be advertised into the BGP process. On router2 I’ll use various access-lists and prefix-lists to see what kind of results I get. Remember though that prefix-lists can be used with other routing protocols and not just BGP.
This is the topology (Click for the full view):
Prefix lists 150x150 Access lists vs Prefix lists
This is the config on each:
R1#sh run | begin bgp
router bgp 100
 no synchronization
 bgp log-neighbor-changes
 network 1.1.1.1 mask 255.255.255.255
 neighbor 10.1.1.10 remote-as 200
 no auto-summary
R2#sh run | begin bgp
router bgp 200
 no synchronization
 bgp log-neighbor-changes
 neighbor 10.1.1.9 remote-as 100
 no auto-summary
I’ll put the following subnets on R1 and advertise them in BGP:
  • 192.168.1.1/24
  • 192.168.2.1/24
  • 192.168.3.1/25
  • 192.168.3.129/25
  • 192.168.4.1/25
  • 192.168.4.129/26
  • 192.168.4.193/26
#R1
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
!
interface Loopback1
 ip address 192.168.1.1 255.255.255.0
!
interface Loopback2
 ip address 192.168.2.1 255.255.255.0
!
interface Loopback3
 ip address 192.168.3.1 255.255.255.128
!
interface Loopback4
 ip address 192.168.3.129 255.255.255.128
!
interface Loopback5
 ip address 192.168.4.1 255.255.255.128
!         
interface Loopback7
 ip address 192.168.4.129 255.255.255.192
!         
interface Loopback8
 ip address 192.168.4.193 255.255.255.192
This is R1′s BGP config now:
R1#sh run | begin bgp
router bgp 100
 no synchronization
 bgp log-neighbor-changes
 network 1.1.1.1 mask 255.255.255.255
 network 192.168.1.0
 network 192.168.2.0
 network 192.168.3.0 mask 255.255.255.128
 network 192.168.3.128 mask 255.255.255.128
 network 192.168.4.0 mask 255.255.255.128
 network 192.168.4.128 mask 255.255.255.192
 network 192.168.4.192 mask 255.255.255.192
 neighbor 10.1.1.10 remote-as 200
 no auto-summary
On Router2, we can see the routes advertised:
R2#sh ip bgp 
BGP table version is 10, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.1/32       10.1.1.9                 0             0 100 i
*> 192.168.1.0      10.1.1.9                 0             0 100 i
*> 192.168.2.0      10.1.1.9                 0             0 100 i
*> 192.168.3.0/25   10.1.1.9                 0             0 100 i
*> 192.168.3.128/25 10.1.1.9                 0             0 100 i
*> 192.168.4.0/25   10.1.1.9                 0             0 100 i
*> 192.168.4.128/26 10.1.1.9                 0             0 100 i
*> 192.168.4.192/26 10.1.1.9                 0             0 100 i
Let’s say I want to filter out the network 192.168.4.0/25. If I use an access-list I need to do it as follows. Create the access list:
R2#conf t
R2(config)#access-list 5 deny   192.168.4.0 0.0.0.127
R2(config)#access-list 5 permit any
Add a rule to the BGP config:
R2#sh run | begin bgp
router bgp 200
 no synchronization
 bgp log-neighbor-changes
 neighbor 10.1.1.9 remote-as 100
 neighbor 10.1.1.9 distribute-list 5 in
 no auto-summary
You can see that the 192.168.4.0/25 route has now been filtered out:
R2#sh ip bgp
   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.1/32       10.1.1.9                 0             0 100 i
*> 192.168.1.0      10.1.1.9                 0             0 100 i
*> 192.168.2.0      10.1.1.9                 0             0 100 i
*> 192.168.3.0/25   10.1.1.9                 0             0 100 i
*> 192.168.3.128/25 10.1.1.9                 0             0 100 i
*> 192.168.4.128/26 10.1.1.9                 0             0 100 i
*> 192.168.4.192/26 10.1.1.9                 0             0 100 i
Let’s say I wanted to filter out the 192.168.4.x/26′s as well. In order to do so I’d have to add another line for each network in my access-list. With a prefix-list it’s much easier to do this. Let’s remove the access-list and start again. NB: Prefix-lists, like access-lists, have a implicit DENY at the end. In an ACL you’ll place a permit any at the end. The prefix-list version of this is to permit 0.0.0.0/0 le 32
First I’ll create the prefix-list:
R2(config)#ip prefix-list exclude_4 seq 5 deny 192.168.4.0/24 ge 25 le 26
R2(config)#ip prefix-list exclude_4 seq 10 permit 0.0.0.0/0 le 32
Now I’ll apply it to the BGP process:
router bgp 200
 no synchronization
 bgp log-neighbor-changes
 neighbor 10.1.1.9 remote-as 100
 neighbor 10.1.1.9 prefix-list exclude_4 in
 no auto-summary
When checking the BGP table I see the following:
R2#sh ip bgp
   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.1/32       10.1.1.9                 0             0 100 i
*> 192.168.1.0      10.1.1.9                 0             0 100 i
*> 192.168.2.0      10.1.1.9                 0             0 100 i
*> 192.168.3.0/25   10.1.1.9                 0             0 100 i
*> 192.168.3.128/25 10.1.1.9                 0             0 100 i
You can see that all the 192.168.4.1/25 and /26s are gone thanks to the prefix-list.
The basics of the prefix list is as follows. If I write
ip prefix-list exclude_4 seq 5 deny 192.168.4.0/24 ge 25 le 26
The /24 tells the IOS to match only the first 24 bits. i.e. 192.168.4 – I then tell the IOS to match only those prefixes that have a subnet mask of /25 or /26. i.e. If I had another network advertised which was 192.168.4.200/27 it would NOT match as even though the 192.168.4 part matches, it has a subnet mask of /27
Let’s say I wanted to now match 192.168.x.x/25 but I wanted to leave the /26′s in place. This would be easy with a prefix list as follows:
R2(config)#ip prefix-list exclude_4 seq 5 deny 192.168.3.0/16 ge 25 le 25 
R2(config)#ip prefix-list exclude_4 seq 10 permit 0.0.0.0/0 le 32
I’ve told the IOS to only match on the first 16 bits, i.e. 192.168 – I then told IOS to only match those prefixes that have a subnet mask of /25. If I apply this to my BGP process I can see that it works as expected:
R2#sh ip bgp          
   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.1/32       10.1.1.9                 0             0 100 i
*> 192.168.1.0      10.1.1.9                 0             0 100 i
*> 192.168.2.0      10.1.1.9                 0             0 100 i
*> 192.168.4.128/26 10.1.1.9                 0             0 100 i
*> 192.168.4.192/26 10.1.1.9                 0             0 100 i
Only the 3 /25′s have disappeared, everything else is still there.
You can also do all of this with extended access-lists, but it’s so much more work, why make life difficult? Once you understand the context of prefix-lists it becomes very easy


#Source: http://mellowd.co.uk/ccie/?p=447

Cisco XRv has been released

Many of you have probably heard of Cisco VIRL or what is now called Cisco Modeling
Labs (CML). CML is due for release later this year and is supposed to include
support for IOS, IOS XE, NXOS and IOS XR.
Last year Cisco released the Cloud Services Router (CSR1000v) which is a virtual
router running IOS XE.
Now Cisco has released the XRv which is a virtual router running IOS XR. This is
great news for anyone that wants to learn IOS XR or to test changes and to try
different concepts on IOS XR.
The VM can be run on ESXi or KVM/QEMU which gives flexibility. The installation
guide is located here.

Every VM needs 3GB of RAM to start but when it’s running it seems to only use 1GB
and has a very low CPU usage.
Resource_usage
At this moment the download is restricted but Cisco is working on moving the restriction.
Expect this to be solved this coming week. XRv will be available in three packages.
Packages
There is restriction on 2 Mbit BW which should not be an issue for labbing purposes.
The initial release has some nasty bugs. So make sure to not use more than one CPU.
Caveats
To be able to run the image the server must meet the following requirements.
Requirements
The complete list of release notes are here.
After you have deployed the VM, which can be done with OVF template or by creating
a VM and using VMDK, don’t forget to create a serial interface and tie this to the
network or you will not be able to see any output from the VM. This is described
in the release notes.
Cisco also provides a free workbook with some basic concepts for IOS XR which can be
found here.
I would also recommend this also free IOS XR workbook by Jeffrey Fry. It’s a great
contribution to the community and it can be found here.
Have fun learning IOS XR!

Source : http://lostintransit.se/ 

BGP Best Path Selection Algorithm

BGP is the protocol used to announce prefixes throughout the internet. It’s a very robust protocol, and very useful to carry lot of prefixes, such as the Internet prefixes or internal client prefixes of an ISP.
When a prefix is received in BGP, the path passes through two steps before being chosen as candidate to populate the RIB.
The first step consists on checking if the path is valid. If it is, the prefix will get into the BGP table, and later the second step of selection will start.
In order to pass this first check, the path must meet the following requirements:
  • The prefix must not been marked as “not-synchronized”
  • There must be a route in the RIB to reach the next-hop
  • For prefixes learned through eBGP sessions, the local ASN must not be in the AS_PATH of the prefix
In the second step, the best path to reach the prefix is selected. If there is only one path, no comparison needed. If there are many paths to reach the prefix, there is a special algorithm that BGP uses to select the best path, and this is what I want to talk about.
This algorithm dictates the following:
  1. Prefer the path with the highest WEIGHT
  2. Prefer the path with the highest LOCAL PREFERENCE
  3. Prefer the path that was locally originated via a network o redistribute command over aggregate-address command
  4. Prefer the path with the lowest AS_PATH
  5. Prefer the path with the lowest ORIGIN type
  6. Prefer the path with the lowest MULTI-EXIT DISCRIMINATOR (MED)
  7. Prefer eBGP over iBGP
  8. Prefer the path with the lowest IGP metric to the BGP next-hop
  9. When both path are external, prefer the one that was received first
  10. Prefer the route that comes from the BGP router with the lowest router ID
  11. If the originator or router ID is the same for multiple paths, prefer the path with the minimum cluster list length
  12. Prefer the path that comes from the lowest neighbor address
As you can see, the selection process is quite long, although in most  cases the selection doesn’t go further than point 8

MPLS : The Core: Intermediate System - Intermediate System -- Part...

MPLS : The Core: Intermediate System - Intermediate System -- Part...: ISIS was originally designed for Open System Interconnect (OSI) protocol Suite. The Connectionless Network Service (CLNS) is been used &amp...

ISIS Fast Convergence

IS-IS, fast convergence is achieved through the following mechanisms:
                (1) Incremental SPF (ISPF)
                (2) Partial route calculation (RPC)
                (3) LSP fast flooding
(4) Intelligent timer (including the SPF intelligent timer and intelligent timer for    generating LSPs)
In addition, fast fault detection can be achieved through BFD for IS-IS, and optimizing the IS-IS network can achieve fast convergence.
Configurations of IS-IS Fast Convergence:
isis 1
 is-level level-2
 cost-style wide
 timer lsp-generation 1 50 50 level-2   //Set the interval for generating the same LSP fragment.
 flash-flood 15 level-2         //Configure LSP fast flooding.
 bfd all-interfaces enable   //Enable BFD for IS-IS to configure BFD for all IS-IS interfaces.
 network-entity 22.0000.0000.0001.00
timer spf 1 50 50             //Set the interval for SPF calculation.
traffic-eng level-2            //Configure IS-IS extension to enable TE on the entire network.
#
interface GigabitEthernet1/0/0
 undo shutdown
ip address 22.1.3.1 255.255.255.0
isis enable 1
isis bfd enable      //Enable BFD for IS-IS for a single interface.
interface GigabitEthernet1/0/1
 undo shutdown
ip address 22.1.2.1 255.255.255.0
isis circuit-type p2p      //Change the type of a broadcast interface to P2P to avoid DIS election and thus speed up route convergence.
isis enable 1
isis bfd enable

Notes: The ISPF algorithm and RPC algorithm are the default algorithms of IS-IS and are enabled by default. Therefore, they do not need to be configured.
The timer lsp-generation command is used to set the interval for generating the same LSP fragment.
The parameter init-interval specifies the initial interval for generating the same LSP fragment. The parameter incr-interval specifies the incremental interval for generating the same LSP fragment. One incr-interval is added each time the network topology changes.
When SPF calculation is performed for the first time, the interval is init-interval. Each time the routes change, the interval is added by incr-interval until the interval reaches max-interval. After the interval reaches max-interval for three times, the interval is reduced to init-interval.
In IS-IS, a device recalculates the shortest path when the LSDB changes. Frequent route calculations consume a lot of resources and thus degrade the system performance. Delaying SPF calculation can improve efficiency in route calculation and reduce the consumption of system resources. If the delay in route calculation is too long, route convergence becomes slow.
To speed up route convergence without affecting the efficiency of routers, you can use an intelligent timer in SPF calculation. This timer automatically adjusts the interval according to the frequency of changes in the LSDB.

Parameters of IS-IS Fast Convergence: