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
Received on Tue Feb 08 2011 - 14:04:09 ART
This archive was generated by hypermail 2.2.0 : Tue Mar 01 2011 - 07:01:49 ART