TASK 4.10 > IP prefix-list R4 deny 155.1.0.4/32 <mechanics of this cmd>

suppose routerr has a ip address of 155.1.0.4/24

 

 

if i use the above prefix list to block said address(155.1.0.4)...doesn't  the BITS CHECKED AND THE MASK HAVE TO MATCH??

 

so 32 bits checked...thats fine

but the mask on R4 is a /24 ..which would make the prefix list fail..

 

but thats the solution presented for task 4.10..which means my understanding of prefix lists is lacking..

 

how does the above logic work when you deny 155.1.0.4/32 but the prefix you are actually denying has a /24 mask....

Comments

  • recent INE CCIE Nic Bhasin comes thru on a phone call!

    the  address you r filtering according to the GATEWAY  ie source of the routing updates is 155.1.0.4. That is the source address in the IP packet....which contains the routing update....

     

    last i checked the IP packet has a source IP field...a destination IP field...but no mask!

     

     

     

  • ip prefix TEST deny 155.1.0.4/32

    Above prefix will only match one node in binary tree which is exactly IP 155.1.0.4.

    I don't remember from which book/web that I read about the explanation of prefix list using binary tree.
    But you can check out this brief blog post by Brian McGahan about "how do prefix lists work"
    http://blog.ine.com/2007/12/26/how-do-prefix-lists-work/ 

     

  • pay attention to the detail my friend...

    i'll quote FROM THAT BLOG (which i've read already)

    """ip prefix-list LIST permit 1.2.3.0/24″ would be an exact match for the prefix 1.2.3.0 with a subnet mask of 255.255.255.0. """

     

    so the ip prefix TEST deny 155.1.0.4/32 would not match 155.1.0.4 since router 4 has a mask of /24. 

    ie with JUST a /len option the number of bits checked AND the mask has to EXACTLY MATCH...those are the rules..and i didn't make em!

     

    however the GATEWAY command in the distribute list makes the matching of the mask a moot point since there is no mask ion the IP packet.

    with the gateway option..you r looking at the IP packet NOT the route update inside the packet..thats my best guess...

     

    however if you can find the binary tree stuff..i'd sure like to look at it!

     

  • Hi all,

       So in this task you need to filter RIP updates received from a specific source/host (known as gateway). Since the source address always identifies a host it makes more sense to use in the prefix-list 155.1.0.4/32, however for this case also 155.1.0.4/24 and 155.1.0.4/26 will do the trick. In the same time, for the router the prefix-list entry 155.1.0.4/24 makes no sense (a host IP with a subnet mask) so it will automatically convert this entry to 155.1.0.0/24 and this entry will NOT match on the source of the RIP update which is 155.1.0.4. When you use prefix-list with the "gateway" option, the mask matched in the prefix-list entry is simpli ignored (basically the prefix-list behaves in this case as an standard ACL which says deny host 155.1.0.4).

    Good luck with your studies!

  • Hi all,

       So in this task you need to filter RIP updates received from a specific source/host (known as gateway). Since the source address always identifies a host it makes more sense to use in the prefix-list 155.1.0.4/32, however for this case also 155.1.0.4/24 and 155.1.0.4/26 will do the trick. In the same time, for the router the prefix-list entry 155.1.0.4/24 makes no sense (a host IP with a subnet mask) so it will automatically convert this entry to 155.1.0.0/24 and this entry will NOT match on the source of the RIP update which is 155.1.0.4. When you use prefix-list with the "gateway" option, the mask matched in the prefix-list entry is simpli ignored (basically the prefix-list behaves in this case as an standard ACL which says deny host 155.1.0.4).

    Good luck with your studies!

     

    however the GATEWAY command in the distribute list makes the matching of the mask a moot point since there is no mask ion the IP packet.

     

    thats what i ws saying above!!!   ...however...it is greately encouraging to have a CCIE confirm what you were thinking! so Thankyou :-)

     

    i win i win![:D]

Sign In or Register to comment.