- RFC 2453 – RIP Version 2
- Distance Vector IGP.
- Routers only know what directly connected neighbours tell them (Routing by Rumour). Routers only know what is the routing as it told by neighbours but does not actually know the state/condition of the route itself.
Two routers R9 and R7 where R7 is connected to the rest of the network and R9 is the edge network. All of the network is exchanging routes via RIP version 2 with no-summary option.
R7 has 126.96.36.199/24 with metric of 2 received from the network and advertise this 188.8.131.52/24 to R9 via its G0/1.79 interface.
R7#sh ip route 184.108.40.206 Routing entry for 220.127.116.11/24 Known via "rip", distance 120, metric 2 Redistributing via rip Last update from 18.104.22.168 on GigabitEthernet0/1.37, 00:00:05 ago Routing Descriptor Blocks: * 22.214.171.124, from 126.96.36.199, 00:00:05 ago, via GigabitEthernet0/1.37 Route metric is 2, traffic share count is 1
R9 received the advertisement of network 188.8.131.52/24 from R7 as below. R9 has 184.108.40.206/24 with metric of 3.
R9#sh ip route 220.127.116.11 Routing entry for 18.104.22.168/24 Known via "rip", distance 120, metric 3 Redistributing via rip Last update from 22.214.171.124 on GigabitEthernet0/1.79, 00:00:04 ago Routing Descriptor Blocks: * 126.96.36.199, from 188.8.131.52, 00:00:04 ago, via GigabitEthernet0/1.79 Route metric is 3, traffic share count is 1
At this stage, we understand now that R7 has route to network 184.108.40.206/24 with metric of 2 and R9 has the route to network 220.127.116.11/24 with metric of 3.
RIP is a distance vector routing protocol where metric is used to denote how many hops it takes to reach the destination. In this case, it will take 2 hops for R7 to reach network 18.104.22.168/24 and 3 hops for R9. It is also true that R9 is 1 hop further away from the network 22.214.171.124/24 than R7.
The metric addition is not added when the routing advertisement received on R9, but it is added when it is advertised out from R7.
R7#debug ip rip RIP: sending v2 update to 126.96.36.199 via GigabitEthernet0/1.79 (188.8.131.52) RIP: build update entries <omitted> 184.108.40.206/24 via 0.0.0.0, metric 3, tag 0 <omitted> R9#debug ip rip RIP: received v2 update from 220.127.116.11 on GigabitEthernet0/1.79 <omitted> 18.104.22.168/24 via 0.0.0.0 in 3 hops <omitted>
One of the way to manipulate the metric value is commonly known using offset-list (I’m sure if you study, by now you know how to manipulate this without using offset-list, right?). Offset-list will increase the existing metric value that is sent or received.
For example, using offset-list with value of 5 in R7 will increase the metric to 8. R7 will take the existing metric of 2, added with 1 when sending it out, added with 5 via offset-list. Total will be 8.
R7(config)#ip access-list st ACLRIPOFFSET R7(config-std-nacl)#permit host 22.214.171.124 R7(config-std-nacl)#exit R7(config)#router rip R7(config-router)#offset R7(config-router)#offset-list ? <0-99> Access list of networks to apply offset (0 selects all networks) <1300-1999> Access list of networks to apply offset (expanded range) WORD Access-list name R7(config-router)#offset-list ACLRIPOFFSET ? in Perform offset on incoming updates out Perform offset on outgoing updates R7(config-router)#offset-list ACLRIPOFFSET out ? <0-16> Offset R7(config-router)#offset-list ACLRIPOFFSET out 5 G0/1.79 R7(config-router)#do debug ip rip R7(config-router)#do clear ip route * RIP: sending v2 flash update to 126.96.36.199 via GigabitEthernet0/1.79 (188.8.131.52) RIP: build flash update entries <omitted> 184.108.40.206/24 via 0.0.0.0, metric 8, tag 0 <omitted>
On R9 we see the metric is now 8
R9#debug ip rip RIP protocol debugging is on R9#clear ip route * RIP: sending request on GigabitEthernet0/1.79 to 220.127.116.11 RIP: received v2 update from 18.104.22.168 on GigabitEthernet0/1.79 <omitted> 22.214.171.124/24 via 0.0.0.0 in 8 hops <omitted> R9#u all All possible debugging has been turned off R9#sh ip route 126.96.36.199 Routing entry for 188.8.131.52/24 Known via "rip", distance 120, metric 8 Redistributing via rip Last update from 184.108.40.206 on GigabitEthernet0/1.79, 00:00:06 ago Routing Descriptor Blocks: * 220.127.116.11, from 18.104.22.168, 00:00:06 ago, via GigabitEthernet0/1.79 Route metric is 8, traffic share count is 1
Some little notes here when using the ACL:
– Also, the update itself does contain the subnet mask information (it’s RIP version 2) but using host address in the ACL is just fine.
– Either standard numbered or standard named ACL will work just fine but cannot use extended ACL.
R7(config)#no ip access-list st ACLRIPOFFSET R7(config)#ip access-list ext ACLRIPOFFSET R7(config-ext-nacl)#permit host 22.214.171.124 host 126.96.36.199 R7(config-router)#offset-list ACLRIPOFFSET out 5 g0/1.79 Access-list type conflicts with prior definition % This command only accepts named standard IP access-lists. R7(config-router)#offset-list 110 out 5 % Invalid access list name. R7(config-router)#offset-list 10 out 5 R7(config-router)#
Storm Control blocks an interface upon receiving unicast, multicast, or broadcast packets flood based on the threshold value within one second period of time. This can be handy to prevent or at least reduce network flooding activities that can impact the network performance.
When the offending traffic reaches the Rising Threshold (RT), the interface blocks all traffic until the offending traffic rate drops below the Falling Threshold (FT). If FT is not specified, only RT will be used to measure.
The threshold value is from 0 to 100 where as 0 is to block any traffic and 100 is turning off the limit. The threshold value can be bits-per-second (bps), packets-per-second (pps), or percentage.
I have been using INE (Internetwork Expert) CCIE RS rack rental but sometimes I find it a bit too slow for telnet response. So, with the advent of Cisco VIRL I have created the similar lab topology so I can lab the workbooks with fast response.
Initial configuration is saved in the .virl file but it is also available in a separate file just in case VIRL does not load the full config (in this case VLANs).
Topology diagram is also available with the conversion from INE lab to VIRL lab.
Spanning Tree Protocol (STP) is a protocol to ensure there is no loop in layer 2 network. This protocol was invented by Radia Perlman in 1985 and published as a standard originally as IEEE 802.1D-1990.
In essence, STP works by sending a probe to every layer 2 switches and decides which link should be block if there is a loop.
Initially STP was used with one instance. This is when there was no understanding of VLAN which was introduced later in IEEE 802.1Q. Mono Spanning Tree runs a single Spanning Tree for all VLANs. Since it uses one Spanning Tree instance for all VLANs, it lacks the ability to engineer one path over another. All VLANs will have to share the same path and fate.