Thanks for the confirmation!I think I was just a little confused being under RIP it seemed like it should be out to OSPF as opposed to in from OSPF but it makes perfect sense now. Thanks for the response I may use this tactic in the lab when there aren't a bunch of routes to filter.
Cheers! From: mark salmon [mailto:[email protected]] Sent: Sunday, October 16, 2011 1:19 PM To: Di Bias, Steve Cc: [email protected] Subject: Re: [OSL | CCIE_RS] convoluted logic Duh (on me that is) you are correct. it'snot backward, its from the perspective of the output from the routing table, so it OSPF routes from the routing table. Juniper uses this "reverse" logic too. "Question with boldness even the existence of a God; because, if there be one, he must more approve of the homage of reason, than that of blind-folded fear." Thomas Jefferson " Where ignorance is bliss 'tis folly to be wise" --- On Sun, 10/16/11, Di Bias, Steve <[email protected]> wrote: From: Di Bias, Steve <[email protected]> Subject: Re: [OSL | CCIE_RS] convoluted logic To: "Mark Salmon" <[email protected]> Cc: "[email protected]" <[email protected]> Date: Sunday, October 16, 2011, 11:57 AM Well the routes originated in RIP and were still in OSPF due to the reverse logic with the "distribute-list out ospf" command. You're correct in that the command prevents route feedback however my question is why was the command implemented backwards? You would think that this command would prevent these routes from going into OSPF, but like I stated in my original email this command prevents routes from coming back into RIP. So basically this command seems to control what OSPF sends to RIP instead of other way around. Sent from G2 Mark Salmon <[email protected]> wrote: If the routes are already in OSPF before bringing redistributed into rip then they will be in the OSPF domain since the lsdb in each area must be the same. The config below did not show where the routes originate. However if the scenario says to prevent routing loops without using a route map this is another way to do that. Remember if the original routes are redistributed into ospf using default ospf type and metric it's possible to inadvertently cause either sub optimal routing or routing loops On Oct 16, 2011, at 11:37 AM, "Di Bias, Steve" <[email protected]</mc/[email protected]>> wrote: I don't have them at the moment and my first thought is to agree with you, however the logic is seems to be flipped and the routes were in OSPF on my neighboring routers. After doing some research it seems like this command prevents route feedback (e.g. the routes are denied from coming back into RIP). Personally I just use route tags but I found this command to be rather interesting and yet convoluted at the same time. Sent from G2I mark salmon <[email protected]</mc/[email protected]>> wrote: send us the routing table in the OSPF domain output after the command is executed and rip has updated. it appears that the 10.10.10.0/24 and 10.10.11/24 should be denied. "Question with boldness even the existence of a God; because, if there be one, he must more approve of the homage of reason, than that of blind-folded fear." Thomas Jefferson " Where ignorance is bliss 'tis folly to be wise" --- On Sun, 10/16/11, Di Bias, Steve <[email protected]</mc/[email protected]>> wrote: From: Di Bias, Steve <[email protected]</mc/[email protected]>> Subject: [OSL | CCIE_RS] convoluted logic To: "[email protected]</mc/[email protected]>" <[email protected]</mc/[email protected]>> Date: Sunday, October 16, 2011, 1:03 AM Hey Experts! It's really not that difficult but I'm trying to understand Cisco's convoluted logic with the following commands/scenario. Let's say we are doing mutual redistribution between OSPF and RIP on R1 (and possibly some other redistribution point as well) - For the sake of sanity we'll just look at the commands on R1. The main focus here is the "distribute-list RIP-ROUTES out ospf 1" which causes some confusion for me. router rip redistribute ospf 1 metric 3 distribute-list RIP-ROUTES out ospf 1 ip access-list standard RIP-ROUTES deny 10.10.10 0.0.0.255 deny 10.10,11.0 0.0.0.255 permit any >From the looks of it this command would prevent the 10 dot networks from being >advertised over to OSPF, however the opposite seems to be true. In other words >this command seems to control what RIP receives in from OSPF. This to me is convoluted and kind of gives me a headache. Can someone shed some light as to why it's this way and why I would use it? Thanks! UHS Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient (s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this information is prohibited. If this was sent to you in error, please notify the sender by reply e-mail and destroy all copies of the original message. _______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com<http://www.ipexpert.com> Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com<http://www.PlatinumPlacement.com> UHS of Delaware, Inc. Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this information is prohibited, and may be punishable by law. If this was sent to you in error, please notify the sender by reply e-mail and destroy all copies of the original message. UHS of Delaware, Inc. Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this information is prohibited, and may be punishable by law. If this was sent to you in error, please notify the sender by reply e-mail and destroy all copies of the original message. UHS Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient (s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this information is prohibited. If this was sent to you in error, please notify the sender by reply e-mail and destroy all copies of the original message. _______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com
