Pete's Packet

Limitless

  • Catagories

  • Global visitors

    free counters
  • RSS CCIE Jobs – Metro NY area

Archive for the ‘RIP’ Category

Day 94 RIP notes

Posted by Peter Kurdziel on June 11, 2009

RIP notes

  1. ip summary-address will suppress more specific routes in RIP. So you do not have to configure an distribute-list.
  2. watch the tasks wording.
  3. configure RIP for unicast ONLY you need a neighbor statement (to enable unicast) and you need to disable broadcast / multicast by using passive-interface.
  4. ran into an issue with authentication failed after changing from md5 to text authentication. I removed the authentication config under the interface and readded it and it started working.
  5. req: send updates out necessary interfaces only, loop0 sneaked in there for me. Found it by change by using debug ip rip events. solution: config passive for the loopbacks.
  6. when changing metrics with an offset-list config the offset-list close to the source. I got it to work on the closest router with in/out and on the router that needed to see the metric with offset in. All solutuions worked no restrictions based on the task.
  7. req: prepare for a futute vlan (secondary address on an interface) solution: disable ip split-horizon or no validate update source on the other router.
  8. when connecting to non-cisco devices you need to disable to holddown. timers basic 30 180 0 240

Q. How is IP split horizon handled on Frame Relay interfaces?


A. IP split horizon checking is disabled by default for Frame Relay encapsulation to allow routing updates to go in and out of the same interface. An exception is the Enhanced Interior Gateway Routing Protocol (EIGRP) for which split horizon must be explicitly disabled.

Configuring Frame Relay subinterfaces ensures that a single physical interface is treated as multiple virtual interfaces. This capability allows you to overcome split horizon rules so packets received on one virtual interface can be forwarded to another virtual interface, even if they are configured on the same physical interface.

Posted in FRAME-RELAY, RIP, Routing & Switching Lab | Leave a Comment »

Passive-interface command behavior in RIP, EIGRP & OSPF

Posted by Peter Kurdziel on June 5, 2009

Passive-interface command behavior in RIP, EIGRP & OSPF

from http://networkers-online.com/blog/2008/08/how-to-avoid-dns-lookup-when-mistyping-a-command/

Passive-interface command is used in all routing protocols to disable sending updates out from a specific interface. However the command behavior varies from o­ne protocol to another.

In RIP this command will disable sending multicast updates via a specific interface but will allow listening to incoming updates from other RIP speaking neighbors.

This simply means that the router will still be able to receive updates o­n that passive interface and use them in the routing table.

In EIGRP the passive-interface command stops sending outgoing hello packets, hence the router can not form any neighbor relationship via the passive interface. This behavior stops both outgoing and incoming routing updates.

In OSPF the passive-interface has a similar behavior to EIGRP. The command suppresses hello packets and hence neighbor relationships.

I have o­nly o­ne final note here regarding sending unicast updates:

If you used the neighbor command under the RIP process, the router will send unicast updates as well as multicast updates.The passive-interface command must be used disable multicast updates and allowing o­nly unicast.

In EIGRP the neighbor command disables multicast updates o­n an interface by default and allows o­nly unicast updates.

Posted in EIGRP, OSPF, RIP, Routing & Switching Lab | Leave a Comment »

Troubleshooting RIP notes

Posted by Peter Kurdziel on May 18, 2009

Notes from Routing TCP/IP vol2

Problem: RIP Routes Not in the Routing Table

The possible causes for this problem are as follows:

  • Missing or incorrect network statement
  • Layer 2 down
  • Distribute list blocking the route
  • Access list blocking RIP source address
  • Access list blocking RIP broadcast/multicast
  • Incompatible version type
  • Mismatch authentication key (RIP-2)
  • Discontiguous network
  • Invalid source
  • Layer 2 problem (switch, Frame Relay, other Layer 2 media)
  • Offset list with a large metric defined
  • Routes that reached RIP hop-count limit
  • Sender problem

Problem: RIP Is Not Installing All Possible Equal-Cost Paths—Cause: maximum-path Command Restricts RIP from Installing More Than One Path

By default, Cisco routers support only four equal paths for the purpose of load balancing. The maximum-path command can be used for up to six equal-cost paths. If the command is not configured properly, it can cause a problem, as discussed in this section. When con-figured improperly, the maximum-path command allows only one path to the destination, even though more than one path exists. Configuring the command as maximum-path 1 should be done only when load balancing is not desired.

Troubleshooting RIP Routes Advertisement

Two of the most prevalent problems that can go wrong on the sender’s end deal with RIP route advertisement:

  • The sender is not advertising RIP routes.
  • Subnetted routes are missing.

Problem: Sender Is Not Advertising RIP Routes

causes of the problem

  • Missing or incorrect network statement
  • Outgoing interface that is down
  • distribute-list out blocking the routes
  • Advertised network interface that is down
  • Outgoing interface defined as passive
  • Broken multicast capability (encapsulation failure in Frame Relay)
  • Misconfigured neighbor statement
  • Advertised subnet is VLSM
  • Split horizon enabled

Problem: Subnetted Routes Missing from the Routing Table of R2—Cause: Autosummarization Feature Is Enabled

Solution: no auto-summary

Troubleshooting Routes Summarization in RIP

  • Autosummarization is off.
  • ip summary-address is not used

Problem: RIP-2 Routing Table Is Huge— Cause: Autosummarization Is Off

Solution: no auto-summary

Problem: RIP-2 Routing Table Is Huge— Cause: ip summary-address Is Not Used

Troubleshooting RIP Redistribution Problems

Any update with a metric greater than 15 will not be considered for entry into the routing table.

Posted in Real World, RIP, Routing & Switching Lab | Leave a Comment »

some redistribution tips

Posted by Peter Kurdziel on May 5, 2009

 

advertise l0 into rip w/o the net cmd and a metric of 10
r1
interface Loopback0
 ip address 150.1.1.1 255.255.255.0
 ip ospf network point-to-point
end
route-map CONNECTED>RIP permit 10
 match interface Loopback0
 
router rip
 version 2
 redistribute connected metric 10 route-map CONNECTED>RIP
 network 140.1.0.0
 no auto-summary
r4
Rack1R4(config-router)#   do sho ip route rip
     150.1.0.0/24 is subnetted, 10 subnets
R       150.1.1.0 [120/10] via 140.1.14.1, 00:00:00, Ethernet0/0
==================================================
r5 rip routes = 500  / r4 routes = 400
Rack1R5(config)#router os 1  
Rack1R5(config-router)#$bute rip metric 500 subnets route-map OSPF>RIP       
Rack1R5(config-router)#no route-map OSPF>RIP
Rack1R5(config)#route-map RIP>OSPF
Rack1R5(config-route-map)#set metric 500
Rack1R5(config-route-map)#router ospf 1
Rack1R5(config-router)#redistribute rip subnets route-map RIP>OSPF
Rack1R5(config-router)#
this did not work right because  I was limiting what routes were tagged with 500 because in the first route mp OSPF>RIP is matched the interface.

advertise loop0  into rip w/o the net cmd and a metric of 10

r1

interface Loopback0

 ip address 150.1.1.1 255.255.255.0

 ip ospf network point-to-point

end

 

route-map CONNECTED>RIP permit 10

 match interface Loopback0

 

router rip

 version 2

 redistribute connected metric 10 route-map CONNECTED>RIP

 network 140.1.0.0

 no auto-summary

 

r4

Rack1R4(config-router)#   do sho ip route rip

     150.1.0.0/24 is subnetted, 10 subnets

R       150.1.1.0 [120/10] via 140.1.14.1, 00:00:00, Ethernet0/0

 

 

==================================================

 

r5 rip routes = 500  / r4 routes = 400

 

Rack1R5(config)#router os 1  

Rack1R5(config-router)#$bute rip metric 500 subnets route-map OSPF>RIP       

Rack1R5(config-router)#no route-map OSPF>RIP

Rack1R5(config)#route-map RIP>OSPF

Rack1R5(config-route-map)#set metric 500

Rack1R5(config-route-map)#router ospf 1

Rack1R5(config-router)#redistribute rip subnets route-map RIP>OSPF

Rack1R5(config-router)#

this did not work right because  I was limiting what routes were tagged with 500 because in the first route mp OSPF>RIP it was matching the interface.

Posted in OSPF, Redistribution, RIP, Routing & Switching Lab | Leave a Comment »

Notes

Posted by Peter Kurdziel on December 31, 2008

I’ve been updating older NOTES threads but this blog does not push them to the front page.

http://usaccie.wordpress.com/2008/12/27/irdp-notes/

http://usaccie.wordpress.com/2008/12/27/odr-notes/

http://usaccie.wordpress.com/2008/12/26/frame-relay-notes/

http://usaccie.wordpress.com/2008/12/17/eigrp-notes/

http://usaccie.wordpress.com/2008/12/12/rip-notes/

http://usaccie.wordpress.com/2008/11/07/ospf-notes/

http://usaccie.wordpress.com/2008/11/06/bgp-notes/

Posted in BGP, EIGRP, FRAME-RELAY, IRDP, ODR, OSPF, RIP, Routing & Switching Lab | Leave a Comment »

RIP notes

Posted by Peter Kurdziel on December 12, 2008

change the default rip timers – sh ip proto to see what they are.

router rip
ver 2
timers basic 60 360 360 480
————————————————-

delay a regular periodic update by 100 ms after receiving an update
router rip
ver 2
timers basic 60 360 360 480 100 < — this is the sleep timer.
—————————————————————

supress a flash update if the regular update is due in 10 seconds or less
router rip
ver 2
flash-update-theshold 10
——————————————————————–

md5 authentication in ripv2

key chain MD5
key 1
key-string ciscomd5

int e0/0
ip rip authentication key-chain MD5
ip rip authentication mode md5
———————————————————————–
R1 and bb1 are in different rip domains  but you still want to receive rip routes from bb1
router rip
ver 2
no validate-update-source
——————————————————————-
allow only prefix-length of /10 – /26 in the routing table- do not use neighbor to accomplish this task.

ip prefix-list NET seq 5 permit 0.0.0.0/0 ge 10 le 26 <– this identify’s routes with that have a prefix length of /10 – /26
ip prefix-list BB1 seq 5 permit 131.1.1.1.1/32 < — identify’s BB1 prefix
router rip
distribute-list prefix NET gateway BB1 in e0/0
——————————————————————————
Router(config-router)# offset-list [access-list-number | access-list-name] {in | out} offset [interface-type interface-number]

——————————————————–

conf t
router eig 100
no auto
net 131.1.112.0 0.0.0.255

inject a default route into rip v2 if one of the 2 networks are advertised by bb2 are in the routing table.

access-list 1 permit 11.1.1.0 0.0.0.255
access-list 1 perm 12.1.1.0 0.0.0.255

route-map MATCHIPINTABLE
match ip add 1

router rip
default-information originate route-map MATCHIPINTABLE

do not allow r4 to advertise networks from bb1 to downstream neighbors. Anything past a hop count of 15 will be dropped.

access-list 1 permit 103.0.0.0 0.63.255.255 log
access-list 1 permit 104.0.0.0 0.31.255.255
access-list 1 permit 105.0.0.0 0.3.255.255 log
access-list 1 permit 107.1.1.0 0.0.0.63
access-list 1 permit 108.1.1.64 0.0.0.63
access-list 1 permit 109.1.4.0 0.0.3.255

router rip
version 2
timers basic 60 360 360 480
offset-list 1 out 12 Serial1/0.12 < — offset the routing metric by 12 so next hope will be 14
offset-list 1 out 13 Serial1/0.14 < — offset the routing metric by 12 so next hope will be 15
no validate-update-source <——- do not validate the route’s update source.

——————————————–
supress periodic ripv2 uipdates. routers should only send updates if there is a topology change.
int s1/0./13
ip rip triggered
——————————————–

send unicast updates
conf t
router rip
passive int e0/1
nei 131.1.24.2
———————————–

send via rip2 updates via broadcast
int e0/0
ip rip v2-broadcast

debug ip rip
RIP protocol debugging is on
R6(config-if)#
*Mar  1 00:58:38.799: RIP: sending v2 update to 255.255.255.255 via Ethernet0/0 (131.1.56.6
————————-

advertise a single summary address
150.1.0.3 /24
150.1.1.3 /24
150.1.2.3 /24
150.1.3.3 /24

int s1/0.31
ip summary-address rip 150.1.0.0 255.255.252.0
———————————————-

r1 is a high speed rtr. r3 is a slow rtr
config r1 to wait 10msec between rip packets
config r3 to increase its RIP queue depth to 75

r1
conf t
router rip
output-delay 10

r3
conf t
router rip
input-queue 75
————————-

configure r6 so that r4 recieves even routers from r6 and odd routes from r5.

Loopback0                  160.1.0.6       YES manual up                    up
Loopback1                  160.1.1.6       YES manual up                    up
Loopback2                  160.1.2.6       YES manual up                    up
Loopback3                  160.1.3.6       YES manual up                    up
Loopback9                  160.1.9.6       YES manual up                    up

access-list 1 permit 160.1.1.0 0.0.254.255
access-list 2 permit 160.1.0.0 0.0.254.255

router rip
ver 2
offset-list 2 out 15 e0/0    <- to r5 -since it’s 15 this will drop even routes to r5, sending odd routes
offset-list 1 out 15 s1.0.64 <- to r4 -since it’s 15 this will drop odd routes to r4, sending even routes
net 160.1.0.0

R4(config-router)#do sho ip route 160.1.0.0 ?
% Unrecognized command
R4(config-router)#do sho ip route 160.1.0.0
Routing entry for 160.1.0.0/24, 5 known subnets
Redistributing via rip

R       160.1.1.0 [120/2] via 131.1.45.5, 00:00:02, Serial1/0.45 — = r5
R       160.1.0.0 [120/1] via 131.1.46.6, 00:00:39, Serial1/0.46 — = r6
R       160.1.3.0 [120/2] via 131.1.45.5, 00:00:02, Serial1/0.45 — = r5
R       160.1.2.0 [120/1] via 131.1.46.6, 00:00:39, Serial1/0.46 — = r6
R       160.1.9.0 [120/2] via 131.1.45.5, 00:00:02, Serial1/0.45 — = r5
—————————————————————————————————————–

config r2 so that it advertises all rip routes to bb3 without chaning the vlan info on cat
router rip
no validate-update-source
net 131.1.0.0

sw-1
conf t
monitor session 1 source inter f1/3 both
monitor session 2 destination inter f1/11
——————————————————————–

configure clear text authentication ———(FYI with clear text authentication the numbers do not need to match)
config t
key chain CLEAR
key 1
key-string cisco

int e0/0
ip rip authen key-chain CLEAR
————————————————————————-

conifg ripv2 MD5 authentication

key chain MD5
key 1
key-string cisco23

int e0/1
ip rip authentica key-chain MD5
ip rip authentica mode md5
——————————————————————————

configure r2 so that it receives all routes form R3. R3 ignores all v2 packets fomr R2 because of invalid authentication.
r2
key chain MD5
key 2 <—————-
key-string cisco23
———————– in ripv2 md2 if the keys do not match the higher key will receive all the routes and it will

polulate all the received routes in the routing table. The router with the lower key will totally ignore all routes received

for the other router.
——————————————————————————————————————-

if the interface is configured in a multipoint using a sub interface manner then IP split horizon is ENABLED.
sh ip int int s1/0.23
split horizon is enabled

if the interface is configured in a multipoing using the physical interface then IP split horizon is DISABLED.
sh ip int s1/0
split horizon is diabled
———————————————————————————————–

ppp over frame-relay

conf t
int virtual-template 123
ip address 10.1.1.1 255.255.255.0

int s1/0
frame-relay interface-dlci 102 ppp virtual-template 123
————————————————————–

Posted in RIP, Routing & Switching Lab | Leave a Comment »

inject a default route int o RIP as long as the networks are in the routing table

Posted by Peter Kurdziel on November 30, 2008

access-list 1 permit 112.1.1.0 0.0.0.255
access-list 1 permit 112.2.2.0 0.0.0.255

route-map TST per 10
match ip add 1

router rip
default-information originate route-map TST

Posted in RIP, Routing & Switching Lab | Leave a Comment »

route filtering in rip

Posted by Peter Kurdziel on November 30, 2008

Allow only /10-/26  prefixes from BB1

ip prefix-list NET s 5 p 0.0.0.0/0 ge 10 le 26

! allows /10 – / 2 prefixes

ip prefix-list BB1 se 5 permit 131.1.111.111/32

! BB1

router rip

distribute-list prefix NET gateway BB1 in e0/0

Posted in RIP, Routing & Switching Lab | Leave a Comment »

If routers exchanging routing info are in different subnets

Posted by Peter Kurdziel on November 30, 2008

If routers exchanging routing info are in different subnets use no validate-update-source in RIP.

Posted in RIP, Routing & Switching Lab | Leave a Comment »

RIP: authenticate rip updates

Posted by Peter Kurdziel on November 2, 2008

key chain RIPUPDATES
key 1
key-string CISCO

interface Vlan102
ip address 192.10.1.10 255.255.255.0
ip rip authentication mode md5
ip rip authentication key-chain RIPUPDATES
!
router rip
version 2
passive-interface default
no passive-interface Vlan102
network 192.10.1.0
no auto-summary <————- enables support for discontinuous networks.

Posted in RIP, Routing & Switching Lab | Leave a Comment »

 
Follow

Get every new post delivered to your Inbox.