From: T. N. Noble (noble@inserviceindia.com)
Date: Wed Jun 08 2005 - 09:40:04 GMT-3
With this solution I am now completely confused.hi..hi..hi.. I have seen
both the solutions earlier and worked on it in the lab. But the poor memory
is causing problems now. :-(
Need to read / test further.
Thanks,
Noble
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Lee
Donald
Sent: 08 June 2005 11:36
To: 'John Matus'; noble@inserviceindia.com; ccielab@groupstudy.com
Subject: RE: route filtering with wild-card mask
I don't think this is correct.
30.1.0.0 0.0.1.0 will not check the least significant bit and hence can
never know whether it is even or odd.
With a wildcard mask like 0.0.1.0 you are checking the 1st octet, and the
2nd, then you are checking all except the last bit in the 3rd octet and you
have let the last bit flip. When I get my routers back up and running I will
confirm this but this mask wouldn't work for odd and even.
The combination I have always used is
30.1.0.0 255.255.254.255 > even
30.1.1.0 255.255.254.255 > odd
This mask does not check anything but the least significant bit in the 3rd
octet which is what will make it odd or even. The preceding network will
make it even or odd by changing the 3rd octet to suit, i.e. 30.1.0.0 > even
and 30.1.1.0 > odd.
I'll check it and get back.
HTH
Lee.
-----Original Message-----
From: John Matus [mailto:john_matus@hotmail.com]
Sent: Wednesday, June 08, 2005 7:29 AM
To: noble@inserviceindia.com; ccielab@groupstudy.com
Subject: RE: route filtering with wild-card mask
noble........from what i remember reading that does make sense......like i
said, you are matching anything in the third octed with the least
significant bit turned on <for odd>.......but i was doing a lab last week
and it worked just the oposite as expected.....hence my question. it's
perplexing. i wonder if anyone else has had a similar experience with "deny
30.1.0.0 0.0.1.255' denying the "even" routes instead of the odd
john
>From: "T. N. Noble" <noble@inserviceindia.com>
>To: "'John Matus'" <john_matus@hotmail.com>,<ccielab@groupstudy.com>
>Subject: RE: route filtering with wild-card mask
>Date: Wed, 8 Jun 2005 08:44:16 +0300
>
>I have a different understanding of your question. "DENY ANYTHING WITH
>ODD 3rd OCTET" may be looked at based on the provided networks / all
networks.
>
>If it is based on the provided network, then I believe that the ACL
>"access-list 1 deny 30.1.0.0 0.0.1.255" is more correct.
>
>Further if it is looked up on based on all the networks then the ACL
>"deny 30.1.0.0 0.0.1.0" may be correct.
>
>I may be wrong but was trying to put my interpretation of your question.
>
>Thanks,
>
>Noble
>
>
>-----Original Message-----
>From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
>John Matus
>Sent: 08 June 2005 07:57
>To: ccielab@groupstudy.com
>Subject: route filtering with wild-card mask
>
>ok,
>you have networks 30.1.1.0 and 30.1.2.0. you want to deny anything with
>an odd 3rd octed
>
>now, i alway thought that you the access-list should be:
>
>access-list 1 deny 30.1.0.0 0.0.1.255 since you are matching anything
>with the last bit set to 1,
>or
>to deny any thing even you should use:
>
>access-list 1 deny 30.1.0.0 0.0.255.255 since only numbers with the
>least significant bit set to zero are even................but lately
>when i've been configuring offset-lists my findings have been just the
>opposite as anticipated....
>
>it this correct?
>
>as a side note, in the 1st example you can actually use "deny 30.1.0.0
>0.0.1.0" yeah? since you don't need to match the 1, 2, or 4th bit <?>
>
>just trying to get my fact nailed down!
>
>tia
>
>_________________________________________________________________
>Dont just search. Find. Check out the new MSN Search!
>http://search.msn.click-url.com/go/onm00200636ave/direct/01/
>
>_______________________________________________________________________
>Subscription information may be found at:
>http://www.groupstudy.com/list/CCIELab.html
>
This archive was generated by hypermail 2.1.4 : Wed Jul 06 2005 - 14:43:41 GMT-3