There you are Rares ..Thanks a lot.. and by the time I was writing this
email got Carlos's response as well which is comprehensive again.. My
apologies Carlos for giving you a headache....English isn't my first
language you see ;-P
Well . I will now need to play some more with DLs to validate my
understanding of this rule .. but I am feeling better now ;)
Thanks again Carlos and Rares...Much appreciated
Cheers !!
Ravi
On Tue, Feb 8, 2011 at 2:12 PM, Rares Donca <rares.donca_at_gmail.com> wrote:
> Ravi,
>
> As Carlos explained nicely here, in your first design with a DENY_ALL
> prefix-list
> you are denying all routes, therefore no routes gets to the gateway filter
> of distribute-list.
>
> In your second design you are basically doing just that, but you now have
> only one neighbor
> on the filtered interface.
>
>
> Regards,
> Rares
>
> On Tue, Feb 8, 2011 at 4:04 PM, Ravi Singh <way2ccie_at_gmail.com> wrote:
>
>> There is no confusion in the second setup Carlos. The question I posed
>> with
>> the second setup was in relation to your answer for my original email. The
>> second setup was just an add-on to explain my understanding of the
>> situation. If you could please forget the second setup for the time being
>> and have a look at the original first setup and let me know the issue in
>> that configuration.
>>
>> What you are saying is correct and holds good for the dual-link sort of
>> scenario. However my issue was that there is just one interface and the
>> routes from two different routers are being learnt on this one interface.
>> I
>> have applied the distribute-list on the interface and specified the
>> gateway
>> from which I want the routes to be denied.It does not work with the way I
>> tried to make it work and works differently. The details are as specified
>> in
>> my previous emails ..
>>
>> Thanks again ..
>> Ravi
>>
>> On Tue, Feb 8, 2011 at 1:29 PM, Carlos G Mendioroz <tron_at_huapi.ba.ar>
>> wrote:
>>
>> > I think I understand the setup.
>> > But I don't understand what is that confuses you in the second (dual
>> > link) setup.
>> >
>> > So let's see that. You have a dedicated link for each neighbour.
>> > If you only filter R3 link, R2's updates are not affected and they
>> > reach R1 regardless of the filter logic.
>> >
>> > The filter logic would have an impact if you were filtering R2's
>> > updates, and you are not.
>> >
>> > Makes sense ?
>> > -Carlos
>> >
>> > Ravi Singh @ 08/02/2011 10:11 -0300 dixit:
>> >
>> >> No problem Carlos .I anyway appreciate your replies .. Let me try to
>> >> explain again
>> >> In my original email, R1 F0/0 connects to a LAN segment that has two
>> >> other routers connected R2 and R3. When I apply the distribute-list on
>> F0/0
>> >> with a gateway command, all routes are denied regardless of where they
>> are
>> >> coming from. However, the intention was to deny routes coming from R3
>> >> only.So the question here was, why all the routes were denied. Based
>> upon
>> >> the configuration I was expecting the routes from R2 to be allowed.
>> >> In your response, when you said that the filter condition is not
>> getting
>> >> a PASS , I replied back saying the same condition works if R1 has two
>> >> different ethernet interfaces connected to R2 and R3 each. So when I
>> applied
>> >> the distribute-list on the interface connected to R3 it denied all the
>> >> routes coming in from R3 . I did not apply it to the other interface. I
>> >> might not have understood you correctly here but I thought you meant
>> the
>> >> DENY-ALL prefix-list i.e deny 0.0.0.0/0 <http://0.0.0.0/0> le 32 does
>> not
>> >> match any routes and hence the filter-condition does not pass.
>> >>
>> >> In my 2nd response to you, I just explained the setup that I talked
>> about
>> >> in my previous response.
>> >> I think you might have missed the original setup .R1 actually gets the
>> >> same routes from R2 and R3 on the same interface, and I wanted to deny
>> all
>> >> routes coming from R3 only, It does not work if I use a DENY-ALL
>> prefix-list
>> >> and match routes coming from R3. It works if I PERMIT-ALL that is not
>> coming
>> >> from R3.
>> >> Please let me know if this explains it any better. Appreciate your
>> >> responses and any further queries you may have ;-)
>> >> Regards,
>> >> Ravi
>> >> On Tue, Feb 8, 2011 at 12:04 PM, Carlos G Mendioroz <tron_at_huapi.ba.ar
>> <mailto:
>> >> tron_at_huapi.ba.ar>> wrote:
>> >>
>> >> I'm loosing you now. Sorry.
>> >> Your first reply to me was, as I understood it, asking why the
>> >> difference when you use a different interface. And the answer to
>> that
>> >> is that you are not applying the DL to the new interface.
>> >>
>> >> DLs are applied to interfaces, so if no DL applied, then everything
>> >> goes through. As no list applies to F0/0, R2 routes pass.
>> >>
>> >> Or am I missing something ?
>> >> -Carlos
>> >>
>> >>
>> >> Ravi Singh @ 08/02/2011 08:35 -0300 dixit:
>> >>
>> >> No .. Suppose R1 F0/0 connects to R2 and R1 F1/0 connects to R3,
>> >> I apply the distribute-list in command on F1/0 and all routes
>> >> coming in from R3 are denied. What I wanted to say was the
>> >> prefix-lists have not changed , so they are ip prefix-list
>> >> DENY-ALL seq 5 deny 0.0.0.0/0 <http://0.0.0.0/0>
>> >> <http://0.0.0.0/0> le 32
>> >>
>> >> !
>> >> ip prefix-list FROM-R3 seq 5 permit 10.1.1.3/32
>> >> <http://10.1.1.3/32> <http://10.1.1.3/32>
>> >> ! and the distribute-list command changes to
>> >>
>> >> distribute-list prefix DENY-ALL gateway FROM-R3 in
>> FastEthernet1/0
>> >> So, if I understood you correctly, in this scenario as well ,
>> >> the PASS condition is not met and R1 denies everything coming in
>> >> F1/0.. is it ? I then also wonder why does it match the routes
>> >> when it is a permit using 0.0.0.0/0 <http://0.0.0.0/0>
>> >> <http://0.0.0.0/0> le 32 and not when it is a deny ..
>> >> Ravi
>> >>
>> >> On Tue, Feb 8, 2011 at 11:26 AM, Carlos G Mendioroz
>> >> <tron_at_huapi.ba.ar <mailto:tron_at_huapi.ba.ar>
>> >> <mailto:tron_at_huapi.ba.ar <mailto:tron_at_huapi.ba.ar>>> wrote:
>> >>
>> >> Are you applying the distribute-list to both interfaces ?
>> >> -Carlos
>> >>
>> >> Ravi Singh @ 08/02/2011 08:21 -0300 dixit:
>> >>
>> >> Hi Carlos,
>> >> Well .. while trying to get my head round this issue , I
>> >> tried
>> >> the same config in a setup when R1 has two different
>> >> ethernet
>> >> interfaces connected to R2 and R3 i.e R1 F0/0 connects to
>> >> R2 and
>> >> R1 F1/0 connects to R3 . The same prefix-list statements
>> and
>> >> distribute-list works just as expected in that scenario .
>> I
>> >> would assume the same mechanism would be applied in this
>> >> scenario as well ..
>> >> Regards,
>> >> Ravi
>> >>
>> >> On Tue, Feb 8, 2011 at 11:11 AM, Carlos G Mendioroz
>> >> <tron_at_huapi.ba.ar <mailto:tron_at_huapi.ba.ar>
>> >> <mailto:tron_at_huapi.ba.ar <mailto:tron_at_huapi.ba.ar>>
>> >> <mailto:tron_at_huapi.ba.ar <mailto:tron_at_huapi.ba.ar>
>> >> <mailto:tron_at_huapi.ba.ar <mailto:tron_at_huapi.ba.ar>>>> wrote:
>> >>
>> >> Ravi,
>> >> updates have to PASS the filter. When you put prefix
>> >> and gateway
>> >> conditions, they have to pass both.
>> >>
>> >> So in your first config, no route passes the prefix,
>> >> it does not
>> >> matter where it comes from.
>> >>
>> >> -Carlos
>> >>
>> >> Ravi Singh @ 08/02/2011 01:52 -0300 dixit:
>> >>
>> >> Hello Group ,
>> >>
>> >> The below email might seem long in the first
>> >> glance but
>> >> it is a
>> >> simple
>> >> question with a very simple setup .
>> >>
>> >> R1
>> >> |
>> >> |
>> >> ------------------SW
>> >> | |
>> >> | |
>> >> R2 R3
>> >>
>> >> If wordwrap ruins the art, the setup is F0/0 on
>> >> R1, R2 and R3
>> >> each is
>> >> connected to a common LAN segment through SW1. The
>> IP
>> >> Addresses
>> >> on the F0/0
>> >> interfaces are 10.1.1.1/24 <http://10.1.1.1/24>
>> >> <http://10.1.1.1/24>
>> >> <http://10.1.1.1/24>, 10.1.1.2/24 <http://10.1.1.2/24>
>> >> <http://10.1.1.2/24>
>> >> <http://10.1.1.2/24> and 10.1.1.3/24
>> >> <http://10.1.1.3/24> <http://10.1.1.3/24>
>> >> <http://10.1.1.3/24>
>> >>
>> >> respectively. R2 and
>> >> R3 both have the same Loop 1, Loop 2 and Loop 3
>> >> addresses
>> >> which are
>> >> 1.1.1.1/24 <http://1.1.1.1/24> <http://1.1.1.1/24
>> >
>> >> <http://1.1.1.1/24>,
>> >> 2.2.2.2/24 <http://2.2.2.2/24> <http://2.2.2.2/24>
>> >> <http://2.2.2.2/24>
>> >> and 3.3.3.3/24 <http://3.3.3.3/24>
>> >> <http://3.3.3.3/24> <http://3.3.3.3/24>
>> >>
>> >> respectively.
>> >>
>> >>
>> >> R1, R2 and R3 run EIGRP between them. Here is the
>> >> routing
>> >> table
>> >> on R1 under
>> >> normal circumstances
>> >>
>> >> R1#sh ip route eigrp
>> >> 1.0.0.0/24 <http://1.0.0.0/24>
>> >> <http://1.0.0.0/24> <http://1.0.0.0/24> is
>> >>
>> >> subnetted, 1 subnets
>> >>
>> >> D 1.1.1.0 [90/156160] via 10.1.1.3,
>> 00:00:03,
>> >> FastEthernet0/0
>> >> [90/156160] via 10.1.1.2, 00:00:03,
>> >> FastEthernet0/0
>> >> 2.0.0.0/24 <http://2.0.0.0/24>
>> >> <http://2.0.0.0/24> <http://2.0.0.0/24> is
>> >>
>> >> subnetted, 1 subnets
>> >>
>> >> D 2.2.2.0 [90/156160] via 10.1.1.3,
>> 00:00:03,
>> >> FastEthernet0/0
>> >> [90/156160] via 10.1.1.2, 00:00:03,
>> >> FastEthernet0/0
>> >> 3.0.0.0/24 <http://3.0.0.0/24>
>> >> <http://3.0.0.0/24> <http://3.0.0.0/24> is
>> >>
>> >> subnetted, 1 subnets
>> >>
>> >> D 3.3.3.0 [90/156160] via 10.1.1.3,
>> 00:00:03,
>> >> FastEthernet0/0
>> >> [90/156160] via 10.1.1.2, 00:00:03,
>> >> FastEthernet0/0
>> >>
>> >> Now the objective (and the issue ) - I want to
>> >> configure
>> >> distribute-list
>> >> using prefix-lists on R1 to *DENY* everything that
>> >> *COMES* from
>> >> R3 ( bold
>> >> keywords just to stress on logic )
>> >>
>> >> So here are the two prefix-lists that I made
>> >>
>> >> ip prefix-list DENY-ALL seq 5 deny 0.0.0.0/0
>> >> <http://0.0.0.0/0>
>> >> <http://0.0.0.0/0> <http://0.0.0.0/0>
>> >>
>> >> le 32
>> >> !
>> >> ip prefix-list FROM-R3 seq 5 permit 10.1.1.3/32
>> >> <http://10.1.1.3/32>
>> >> <http://10.1.1.3/32> <http://10.1.1.3/32>
>> >>
>> >>
>> >> !
>> >>
>> >> And then I used the below command to achieve what
>> is
>> >> being expected
>> >> router eigrp 100
>> >> distribute-list prefix DENY-ALL gateway FROM-R3
>> in
>> >> FastEthernet0/0
>> >>
>> >> The output on R1 now becomes
>> >>
>> >> R1#sh ip route eigrp
>> >>
>> >> R1#
>> >>
>> >> Basically no routes. So it denies everything
>> >> coming in F0/0,
>> >> even though I
>> >> specified the gateway. BUT , if I change the logic
>> >> i.e
>> >> *PERMIT*
>> >> everything
>> >> that does *NOT* come from R3 , it works just fine
>> .
>> >> Therefore If
>> >> I make the
>> >> prefix-lists as
>> >>
>> >> ip prefix-list NOT-FROM-R3 seq 5 deny 10.1.1.3/32
>> >> <http://10.1.1.3/32>
>> >> <http://10.1.1.3/32>
>> >> <http://10.1.1.3/32>
>> >>
>> >> ip prefix-list NOT-FROM-R3 seq 10 permit
>> 0.0.0.0/0
>> >> <http://0.0.0.0/0>
>> >> <http://0.0.0.0/0>
>> >> <http://0.0.0.0/0> le 32
>> >>
>> >> !
>> >> ip prefix-list PERMIT-ALL seq 5 permit 0.0.0.0/0
>> >> <http://0.0.0.0/0>
>> >> <http://0.0.0.0/0>
>> >> <http://0.0.0.0/0> le 32
>> >>
>> >>
>> >> And the distribute-list as
>> >>
>> >> router eigrp 100
>> >> distribute-list prefix PERMIT-ALL gateway
>> >> NOT-FROM-R3 in
>> >> FastEthernet0/0
>> >>
>> >> The output on R1 is as expected now .
>> >>
>> >> R1#sh ip route eigrp
>> >> 1.0.0.0/24 <http://1.0.0.0/24>
>> >> <http://1.0.0.0/24> <http://1.0.0.0/24> is
>> >>
>> >> subnetted, 1 subnets
>> >>
>> >> D 1.1.1.0 [90/156160] via 10.1.1.2,
>> 00:02:01,
>> >> FastEthernet0/0
>> >> 2.0.0.0/24 <http://2.0.0.0/24>
>> >> <http://2.0.0.0/24> <http://2.0.0.0/24> is
>> >>
>> >> subnetted, 1 subnets
>> >>
>> >> D 2.2.2.0 [90/156160] via 10.1.1.2,
>> 00:02:01,
>> >> FastEthernet0/0
>> >> 3.0.0.0/24 <http://3.0.0.0/24>
>> >> <http://3.0.0.0/24> <http://3.0.0.0/24> is
>> >>
>> >> subnetted, 1 subnets
>> >>
>> >> D 3.3.3.0 [90/156160] via 10.1.1.2,
>> 00:02:01,
>> >> FastEthernet0/0
>> >> R1#
>> >>
>> >> So, the question is What am I doing wrong in the
>> >> first
>> >> method ?
>> >> Are there
>> >> some basic rules that are being broken here ?
>> >>
>> >> Regards,
>> >> Ravi
>> >>
>> >>
>> >> Blogs and organic groups at http://www.ccie.net
>> >> <http://www.ccie.net/>
>> >> <http://www.ccie.net/>
>> >> <http://www.ccie.net/>
>> >>
>> >>
>> >>
>> _______________________________________________________________________
>> >> Subscription information may be found at:
>> >> http://www.groupstudy.com/list/CCIELab.html
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> -- Carlos G Mendioroz <tron_at_huapi.ba.ar
>> >> <mailto:tron_at_huapi.ba.ar>
>> >> <mailto:tron_at_huapi.ba.ar <mailto:tron_at_huapi.ba.ar>>
>> >> <mailto:tron_at_huapi.ba.ar <mailto:tron_at_huapi.ba.ar>
>> >>
>> >> <mailto:tron_at_huapi.ba.ar <mailto:tron_at_huapi.ba.ar>>>>
>> >>
>> >> LW7 EQI Argentina
>> >>
>> >>
>> >>
>> >> -- Carlos G Mendioroz <tron_at_huapi.ba.ar
>> >> <mailto:tron_at_huapi.ba.ar> <mailto:tron_at_huapi.ba.ar
>> >> <mailto:tron_at_huapi.ba.ar>>>
>> >> LW7 EQI Argentina
>> >>
>> >>
>> >>
>> >> -- Carlos G Mendioroz <tron_at_huapi.ba.ar <mailto:
>> tron_at_huapi.ba.ar
>> >> >>
>> >> LW7 EQI Argentina
>> >>
>> >>
>> >>
>> > --
>> > Carlos G Mendioroz <tron_at_huapi.ba.ar> LW7 EQI Argentina
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
Blogs and organic groups at http://www.ccie.net
Received on Tue Feb 08 2011 - 14:23:54 ART
This archive was generated by hypermail 2.2.0 : Tue Mar 01 2011 - 07:01:50 ART