Lessons Learned:
RIP v2 – Version one is now considered legacy and is a
Class-full protocol.
Not a very feature rich protocol. RIP is the most basic of
all dynamic routing protocols.
Distance Vector IGP
-uses split-horizon, poison reverse, and count to infinity
(loop prevention)
-UDP port 520 for transport
Two version
RIPv1
-classful
Updates as broadcast
RIPv2
-Classless
-updates as multicast to 224.0.0.9
RIP – only knows about its directly connected neighbors and
what the neighbors advertise. RIP does now know about the overall topology.
RIP’s distance vector behavior is often called “routing by
rumor” because when the router receives an update in, it has no visibility
about where the update came from. It has no idea about the overall topology.
RIP – Uses UDP port 520 for reachability. If there’s a
firewall between neighbor routers or access-lists, we need to make sure UDP 520
is not filtered.
RIPv2 – is a classless protocol, this means it support the
advertisements of subnets or supersets that are of any VLSM.
RIPv1 – packet does not include a field of the route for the
VLSM address. This means every subnet had to be identical.
EX all / 24’s or all /26’s – as long as the masks are the
same because the subnet mask is not advertised in the updates.
RIPv1 also uses broadcasts for its updates. This means each
device has to process all updates.
RIPv2 – uses a multicast address routing control plane
exchange for its updates.
RIPv2 is classless and so it can support LSM – it has two
fields – one for the address and the subnet.
Configuring and enabling RIP.
Easy process –
-enable the global process:
-router rip
Enable the interface process
-network (address) -
No process number no AS number, etc….
-matches major network only
Verification
-sh ip protocols
-sh ip rip database
-dubug ip rip.
LAB:
R3#
router rip
network 10.0.0.0
network 192.168.23.0
no auto-summary
debug output from initial sync between two peers over
network 192.168.23.0 / 24. Each router R3 and R2 have loopbacks addressed in
the 10.1.x.x /24 space. This is the output from a RIP version 1 initial Sync.
Initial peer update from RIP V1
*Mar 1 00:16:20.347:
RIP: sending request on FastEthernet0/1 to 255.255.255.255
*Mar 1 00:16:22.343:
RIP: sending v1 flash update to 255.255.255.255 via FastEthernet0/1
(192.168.23.2)
*Mar 1 00:16:22.343:
RIP: build flash update entries - suppressing null update
*Mar 1 00:16:27.319:
RIP: received v1 update from 192.168.23.3 on FastEthernet0/1
*Mar 1
00:16:27.319: 10.0.0.0 in 1 hops
*Mar 1 00:16:46.371:
RIP: sending v1 update to 255.255.255.255 via FastEthernet0/1 (192.168.23.2)
*Mar 1 00:16:46.371:
RIP: build update entries - suppressing null update
*Mar 1 00:16:52.859:
RIP: received
v1 update from 192.168.23.3 on FastEthernet0/1
*Mar 1
00:16:52.859: 10.0.0.0 in 1 hops – ( I have
Initial peer update from RIP v2
*Mar 1 00:25:40.299:
RIP: build flash update entries
*Mar 1
00:25:40.299: 10.1.2.0/24 via 0.0.0.0,
metric 1, tag 0
*Mar 1 00:25:40.299:
RIP: sending
v2 flash update to 224.0.0.9 via Loopback1 (10.1.2.1)
*Mar 1 00:25:40.299:
RIP: build flash update entries - suppressing null update
Update after adjacency:
*Mar 1 01:32:58.371:
RIP: received
v2 update from 192.168.23.3 on FastEthernet0/1
*Mar 1
01:32:58.371: 10.1.3.0/24 via
0.0.0.0 in 1 hops
*Mar 1 01:33:22.067:
RIP: sending v2 update to 224.0.0.9 via Loopback1 (10.1.2.1)
*Mar 1 01:33:22.071: RIP: build update entries
*Mar 1 01:33:22.071: 10.1.3.0/24 via 0.0.0.0, metric 2, tag 0
*Mar 1
01:33:22.075: 192.168.23.0/24 via
0.0.0.0, metric 1, tag 0
*Mar 1 01:33:22.083:
RIP: ignored v2 packet from 10.1.2.1 (sourced from one of our addresses)
Note: from the global routing table when configuring RIP
there can only be one rip process.
The network statement tell the RIP process what interfaces
do we want to send updates out of and what interface do we want to listen for
updates on.
The network statement supports only classful networks. This
however doesn't control what is advertised, it simply controls what interface
the routing process is enabled on.
Note: Since the network statement only matches the classful network if we want to run RIP on only one interface and we have other
interfaces in the same classful network we can have issues. We would have to
filter updates coming in via access-lists or configure the interfaces as
passive. Etc.
Once the protocol is enabled, we can verify with the
following commands.
#Sh ip protocols – shows the timers, interfaces, updates,
protocol version and classful networks that RIP is routing for.
R2#sh ip protocols
Routing Protocol is "rip" – running RIIP
Outgoing update
filter list for all interfaces is not set
Incoming update
filter list for all interfaces is not set
Sending updates
every 30 seconds, next due in 24 seconds
Invalid after 180
seconds, hold down 180, flushed after 240
Redistributing: rip
Default version
control: send version 2, receive version 2
Interface Send Recv
Triggered RIP Key-chain
FastEthernet0/1 2 2
Loopback1 2 2
Automatic network
summarization is not in effect
Maximum path: 4
Routing for
Networks:
10.0.0.0
192.168.23.0
Routing Information
Sources:
Gateway Distance Last Update
192.168.23.3 120 00:00:03
Distance: (default
is 120)
Once RIP receives and update in
an interface – they go into the RIP database for processing before they go into
the routing table.
RIP – in RIP there’s two
different data structures. One that has all the routes that we’re advertising
and receiving, this goes into the RIP database. Then the active routes that we
are actually using that go into the routing table or FIB table.
Sh ip rip database:
R3#sh ip rip database
10.0.0.0/8 auto-summary
10.1.2.0/24
[1] via 192.168.23.2, 00:00:10,
FastEthernet0/0
10.1.3.0/24 directly connected, Loopback1
192.168.23.0/24 auto-summary
192.168.23.0/24 directly connected, FastEthernet0/0
Dubug ip rip
R3#
*Mar 1 03:05:13.179: RIP: sending v2 update to
224.0.0.9 via Loopback1 (10.1.3.1)
*Mar 1 03:05:13.183: RIP: build update entries
*Mar 1 03:05:13.183: 10.1.2.0/24 via 0.0.0.0, metric 2, tag 0
*Mar 1 03:05:13.187: 192.168.23.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 03:05:13.195: RIP: ignored v2 packet from
10.1.3.1 (sourced from one of our addresses)
Note: will so any updates
advertised and received – also any authentication errors, etc.
RIP Versions:
Default processing
-send version 1 updates
-listen for versions 1 & 2
updates
Modifying the version
-version (process level)
-ip rip receive version - interface level
-ip rip receive version - interface level
-ip rip send version - interface level
Verification:
-sh ip protocols
Configuration –
No separation between version 1
& 2. IOS will send version 1 updates by default but listen bot v1 and v2.
We can change the default
behavior under each interface in the process. Of globally with the rip then
version, ect.
Global:
R3(config)#router rip
R3(config-router)#version 2
Interface level Commands:
R3(config-if)#ip rip send version
?
1 RIP version 1
2 RIP version 2
R3(config-if)#ip rip send version
2
R3(config-if)#ip rip rec
R3(config-if)#ip rip receive v
R3(config-if)#ip rip receive
version 2
R3(config-if)#
RIP Auto-Summary:
RIPv2 is classless but does
automatic classful summarization be default.
-Disabled with the “no
auto-summary” command under the process.
VLSM is supported within the same
major network.
Example for the classful network
10.1.1.0 /24
10.1.2.0 /24
10.1.3.0 /30
All fall under the classful
network of 10.0.0.0 / 8. Basically the class A, B,C networks, etc.
Classful binary review.
Each Octet is broken into 8 bits.
The first 4 of those bits define the network class.
Example:
00000000 – the first 4 define the
class
Oxxx = Class A netwok
10xx = Class B network
110X = Class C network
1110 = Class D network – reserved
for Multicast
1111 = Class e network.
Advertisements between major
network boundaries are summarized to classful boundary
-again this can result in traffic
black holes.
Sh ip protocols
R3#sh ip protocols
Routing Protocol is
"rip" -- we are running RIP
Outgoing update filter list for all interfaces is not set -- No filter set (distribute list, prefix,
etc)
Incoming update filter list for all interfaces is not set -- No
filter set
Sending updates every 30 seconds, next due in 18 seconds --
Invalid after 180 seconds, hold down 180, flushed after 240 –
after 240 second will be removed from DB and routing table
Redistributing: rip
Default version control: send version 2, receive version 2 –
send and rec version are at 2 because I hard coded them
Interface Send Recv
Triggered RIP Key-chain
FastEthernet0/0 2
2
Loopback1 2 2
Automatic network summarization is not in effect – we are using auto – summary.
Maximum path: 4 -- we
have 4 maximum equal cost paths. Same longest prefix, metric value, we will
install up to 4 routes
Routing for Networks: - what
interfaces will have the protocol enabled on if they fall in the major network
10.0.0.0
192.168.23.0
Routing
Information Sources: -- these are the neighbors that we are learning
RIP from with default AD of 120
Gateway Distance Last Update
192.168.23.2 120 00:00:00
Distance: (default is 120)
Sh ip rip database.
R3#sh ip rip database
10.0.0.0/8 auto-summary -- routing for major networks
10.1.2.0/24
[1] via 192.168.23.2, 00:00:13,
FastEthernet0/0
10.1.3.0/24 directly connected, Loopback1
192.168.23.0/24 auto-summary
192.168.23.0/24 directly connected, FastEthernet0/0
R3#
Note: with the default version 1
- if we receive updates that are VLSM – we will assume the subnet of the mask
that the interface that I was received on. Example – if my interface has a /24
mask, it will assume all the subnets coming from me will have a /24 mask.
Note: Both versions of RIP support the advertisements of host routes.
Configured L0 33
interface Loopback33
ip address 1.2.3.4 255.255.255.255
end
advertised it in RIP
R3(config)#router rip
R3(config-router)#network 1.2.3.4
router rip
version 2
network 1.0.0.0
even though auto-summarization is
on –
the neighbor router still sees
the host route
R2#sh ip route rip
1.0.0.0/32 is subnetted, 1 subnets
R 1.2.3.4 [120/1] via 192.168.23.3, 00:00:28,
FastEthernet0/1
Note: with RIP Version 2 and auto-summary on, the routers will receive
multiple classful summaries about the same major network. When they cross boundaries
they will be summarize to the major network.
No comments:
Post a Comment