ACL bloking eBGP Session

Unanswered Question
Aug 7th, 2009
User Badges:

Extended IP access list eBGP_Port

10 permit tcp any eq www any

20 deny tcp any any eq 1

30 deny tcp any any eq smtp

40 deny tcp any any eq 135

50 deny tcp any any eq 137 138 139

60 deny tcp any any eq 445

70 deny udp any any eq 1

80 deny udp any any eq 25

90 deny udp any any eq 50

100 deny udp any any eq 55

110 deny udp any any eq 70

120 deny udp any any eq 135

130 deny udp any any eq netbios-ns netbios-dgm netbios-ss

140 deny udp any any eq 445

150 deny ip 0.0.0.0 0.255.255.255 any

160 deny ip 10.0.0.0 0.255.255.255 any

170 deny ip 169.254.0.0 0.0.255.255 any

180 deny ip 172.16.0.0 0.0.240.255 any

190 deny ip 192.168.0.0 0.0.255.255 any

200 deny ip 0.0.0.0 252.255.255.255 any

210 deny ip 127.0.0.0 0.255.255.255 any

220 permit ip any any

7609-1#


The eBGP neighbor is 4.71.X.X


Everytime he ACL is applied inbound, it kills the BGP neighbor...


Which line is doing it????


Thanks





  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.9 (6 ratings)
Loading.
Edison Ortiz Fri, 08/07/2009 - 14:15
User Badges:
  • Super Bronze, 10000 points or more
  • Hall of Fame,

    Founding Member

Took your config on the lab:



R1#sh ip access-lists BGP | i matches

200 deny ip 0.0.0.0 252.255.255.255 any (14 matches)

R1#

00:06:55: %BGP-5-ADJCHANGE: neighbor 4.71.1.1 Down BGP Notification sent

00:06:55: %BGP-3-NOTIFICATION: sent to neighbor 4.71.1.1 4/0 (hold time expired) 0 bytes

R1#


HTH,


__


Edison.

Jon Marshall Fri, 08/07/2009 - 14:17
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Edison


Just did the same and get the same result.


I then tried 0.0.0.0 254.255.255.255


and it still dropped it. How exactly is it interpreting the wildcard mask here ?


Jon

Edison Ortiz Fri, 08/07/2009 - 14:35
User Badges:
  • Super Bronze, 10000 points or more
  • Hall of Fame,

    Founding Member

Seeing the same thing and it shouldn't, interesting...


ex-engineer Fri, 08/07/2009 - 15:34
User Badges:

I am confused, too...


I dont have a lab to test this and the equipment is in production now, so I cant touch it...


But in my view, the 252.255.255.255 wildcard mask means that the last 2 bits in the first octet must match, all the 1's are "dont cares." So, the networks that should be blocked -- I think -- are networks 0.0.0.0, 1.0.0.0, 2.0.0.0 and 3.0.0.0.


Am I correct -- in theory?

Jon Marshall Fri, 08/07/2009 - 15:37
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Joe


That was my first thought too altho i'm not entirely sure it is valid hence the reason i then tested with 254.255.255.255.


I think it's safe to say as both Edison and myself labbed it up that it is that line that is stopping your BGP peering but it's a little unclear as to what is happening.


Perhaps i need to to revisit my binary maths :-)


Jon

ex-engineer Fri, 08/07/2009 - 15:54
User Badges:

Jon:


No, I dont think you need to revisit your binary math.


Edison is just as surprised as you are.


OK, that is the line causing the problem, but I want to know why.....you know what I mean? Its not making sense....


Anyway, the eBGP neighbor is on a 4.x.x.x address, so if you do agree that the mask - the way it is now -- will block networks 0 through 3, leaving the 4 network fine, why did you want to try a .254.255.255.255 mask....?

Edison Ortiz Fri, 08/07/2009 - 20:46
User Badges:
  • Super Bronze, 10000 points or more
  • Hall of Fame,

    Founding Member

These are one of those times when I don't have a concise answer..



Jon Marshall Fri, 08/07/2009 - 23:54
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Joe


"why did you want to try a .254.255.255.255 mask....?"


Simply as a test because it didn't make sense to me that 252.255.255.255 was blocking network 4.x.x.x so i tried 254.255.255.255 which definitely shouldn't have but same.


It's definitely something to do with the way the router is interpreting the wildcard mask - will have to play around with it a bit more.


Jon

Jon Marshall Sat, 08/08/2009 - 01:09
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Joe


Quick update on this. From testing in lab it looks like 252.255.255.255 will block any packet from an IP address that's first octet is divisible by 4. ie.


1.1.1.1 -> 3.3.3.1 pings okays

4.4.4.1 gets blocked

5.5.5.1 -> 7.7.7.1 pings okay

8.8.8.1 gets blocked


I haven't tested every IP address from 1.x -> 254.x but i have done a fair few.


I don't know if this is expected behaviour. Wildcard masks are not just the opposite of subnet masks but i think i need to do a bit more reading.


Jon


Jon Marshall Sat, 08/08/2009 - 02:03
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Joe


Further update. Wildcard masks are often seen as the inverse of subnet masks ie.


255.255.255.0 subnet mask =

0.0.0.255 wildcard mask


But whereas subnet mask must be contiguous there is no such requirement for a wildcard mask. So for example -


you can have a wildcard mask of 0.0.0.254 which means only accept even numbers in the last octet of the IP address. So i believe 252.255.255.255 is actually a valid wildcard mask.


Now i just need to sit down with my notepad and do the maths which was never my strong point so it may be a while :-)


Jon

Jon Marshall Sat, 08/08/2009 - 02:11
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Joe


Sorry not the best example.


"But whereas subnet mask must be contiguous there is no such requirement for a wildcard mask. So for example -


you can have a wildcard mask of 0.0.0.254"


what i meant to say was you could have a wildcard mask of


0.0.7.254 so


192.168.8.0 0.0.7.254


would allow all even numbered hosts from the subnets 192.168.8.0 -> 192.168.15.0


so as far as i can see 252.255.255.255 is perfectly valid as a wildcard mask.


Edit - this is also why 254.255.255.255 blocked 4.4.4.1 because it is looking for any IP address that has an even number in the first octet.


Jon

Jon Marshall Sat, 08/08/2009 - 07:07
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Joe


Here is the best explanation i can give -


We'll compare


0.0.0.0 252.255.255.255


with


0.0.0.0 3.255.255.255


with wildcard masks if the bit value is 1 then it means "don't care". If the bit value is a 0 then it mean care -

the exact opposite of a subnet mask.


So putting these into binary and only concentrating on the first octet - see below for why


3.255.255.255 in binary


128 64 32 16 8 4 2 1

0 0 0 0 0 0 0 0 = first octet of network


0 0 0 0 0 0 1 1 = 3


1 1 1 1 1 1 0 0 = 252


1 1 1 1 1 1 1 1 = 255 - all bits are one therefore we don't care what value is in this octet.


Because 255 means we don't care about the value of that octet we can disregard the last 3 octest of the 0.0.0.0 network.


The first octet - if you look at the binary value for 3 and based on 0 meaning care and 1 don't care the wildcard mask

is saying the first 6 bits i care about and the last 2 i don't. So the first six bits must match the network portion ie.


128 64 32 16 8 4

0 0 0 0 0 0 -> first six bits of IP address

0 0 0 0 0 0 -> first six bits of wildcard mask


the last 2 bits can be any value so you end up with the possible values of


2 1 -> note these are the last 2 bits of the first octet


0 0 = 0

0 1 = 1

1 0 = 2

1 1 = 3


so from these values we can say 0.0.0.0 3.255.255.255 =


0.0.0.0

1.0.0.0

2.0.0.0

3.0.0.0


which is pretty much what all of us would probably have said.



Looking at the binary value of 252 the wildcard mask is saying the first six bits i don't care about but the last 2 i do. So

the first six bits can be anything as long as the last 2 bits match. So


128 64 32 16 8 4

0 0 0 0 0 0 first 6 bits of IP address

1 1 1 1 1 1 first 6 bits of wildcard mask


the last 2 bits must be the same value however ie.


2 1 -> note these are last 2 bits of the first octet


0 0 -> this is their value based on the first octet of the network 0.0.0.0


so those last 2 bits can never be anything other than 0, but all the other bits can be anything they want. And because whatever you do with the first six bits the number you end up with will always be divisible by 4 the combination of 0.0.0.0 252.255.255.255 means that it matches every network combination divisible by 4.


Hope this makes sense !


Jon

ex-engineer Sat, 08/08/2009 - 09:57
User Badges:

Jon:


What you are saying DOES make sense, and honestly, I dont know why I found this so confusing yesterday. I guess it's because the wildcard mask was not common and I wasnt used to seeing such a mask.



Just to review where in this thread I think we both went wrong:



Me: "But in my view, the 252.255.255.255 wildcard mask means that the last 2 bits in the first octet must match, all the 1's are "dont cares." So, the networks that should be blocked -- I think -- are networks 0.0.0.0, 1.0.0.0, 2.0.0.0 and 3.0.0.0.


Am I correct -- in theory?"


The answer should have been NO, I am wrong in theory -- or better yet, half right.



YOU: "That was my first thought too altho i'm not entirely sure it is valid hence the reason i then tested with


254.255.255.255."



I think this is exactly what went wrong here.


I was thinking the exact opposite because I got confused. The first half of my statement is right, but the conclusion I drew contradicted that statement. And you agreed with me --- shame on you! :-)


If indeed the last 2 bits MUST match, as I said in my first statement, then, as you said later on in this thread, the first octet of the network number will always be a multiple of 4. As you point out, the last 2 digits MUST ALWAYS BE ZERO, and in binary, 2 bits gives you a result of 4 maximum combinations.


Just to expand on it and get into detail...


...with a network number in the ACL of 00000000.00000000.00000000.00000000 and a wildcard mask of 11111100.11111111.11111111.11111111 - the last 2 digits in the first octet of whatever packet is received on the interface must be "0". That means that network numbers 0.0.0.0 through 0.255.255.255 would be blocked, but 1.0.0.0 through 1.255.255.255,

2.0.0.0 through 2.255.255.255 and 3.0.0.0 through 3.255.255.255 will NOT be blocked because the frst octet in those network

numbers have a "1" in one, or both, of the last 2 binary positions of the first octet, which we already said MUST always be

"0"s for the ACL to match.


Then 4.0.0.0 through 4.255.255.255 will be blocked and 5.0.0.0 through 5.255.255.255, 6.0.0.0 through 6.255.255.255, and 7.0.0.0 through 7.255.255.255 would NOT be blocked because, once again, those network numbers have a number other than "0" in the last 2 bit positions of the first octet.


Then, 8.0.0.0 through 8.255.255.255 will be blockd and so on and so forth....


Do you agree wth this in its entirety??

Jon Marshall Sat, 08/08/2009 - 23:30
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Joe


"shame on you! :-)"


Yes, sorry about that :-)


"Do you agree wth this in its entirety??" - assuming your'e not trying to trick me into agreeing with you so you can tell me i was wrong again then yes :-)


Seriously though, yes i do agree and i learnt a lot from this post as well. Most wildcards you see are just a subnet mask flipped and altho i knew this wasn't always the case it wasn't until i had to work it out that it made more sense.


Jon

ex-engineer Sun, 08/09/2009 - 09:05
User Badges:

Jon, I agree that this is a wacky ACL statement and it confused me, too. No biggie.


By the way, can I ask you for two things -- actually, you and Edision



1.) What exactly does this statement block?


deny ip 0.0.0.0 0.255.255.255


It seems to me that this is ONLY blocking any network number tht starts witha "0.". I think the client is under the impression that the statement blocks all 0.0.0.0/8 addresses? In other words, all class A addresses.


2.) Can you please look at the thread I created in which I compare two ACls and render an opinion?


Thanks again, Jon and Edison.


REALLY appreciate your time and energy very much.



ex-engineer Sun, 08/09/2009 - 09:23
User Badges:

By the way, what ACL statement do I need to block all Class A addresses -- if I wanted to. I dont in this case, but if I did...

Jon Marshall Sun, 08/09/2009 - 11:28
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Joe


Sorry, last post got a bit mixed up -


"1.) What exactly does this statement block?


deny ip 0.0.0.0 0.255.255.255


It seems to me that this is ONLY blocking any network number tht starts witha "0.". I think the client is under the impression that the statement blocks all 0.0.0.0/8 addresses? In other words, all class A addresses."


Agreed.


To block all class A addresses -


0.0.0.0 127.255.255.255


Jon

Jon Marshall Sun, 08/09/2009 - 11:21
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Joe


"1.) What exactly does this statement block?


deny ip 0.0.0.0 0.255.255.255


It seems to me that this is ONLY blocking any network number tht starts witha "0.". I think the client is under the impression that the statement blocks all 0.0.0.0/8 addresses? In other words, all class A addresses."


Agreed, it is only blocking 0.0.0.0/81.) What exactly does this statement block?


deny ip 0.0.0.0 0.255.255.255


It seems to me that this is ONLY blocking any network number tht starts witha "0.". I think the client is under the impression that the statement blocks all 0.0.0.0/8 addresses? In other words, all class A addresses.


If you want to block all class A addresses


0.0.0.0 127.255.255.255


Jon



mbroberson1 Fri, 08/07/2009 - 17:11
User Badges:

From the looks it appears line 200 is invalid in some way. You may also want to verify line 150.


The way this reads is 0.0.0.0 (match host starting at any address to what?) wildcard mask 252.255.255.255 translated to subnetmask would be 3.0.0.0. Looks a bit strange to me.


I would just remove line 200 to see if this helps. If not then also remove 150 for kicks.


HTH,


Brandon



ex-engineer Fri, 08/07/2009 - 17:22
User Badges:

Hi:


We've already established that the cause is line 200


The question now is why...


Please scroll through this thread...



mbroberson1 Fri, 08/07/2009 - 18:27
User Badges:

Hi ex-engineer:


I have read the thread from top to bottom. Your comment "We've already established that the cause is line 200".


Remove line 200 completly, it doesn't make any sense the way it's currently written.


Perhaps if you could better describe your intentions of what you're trying to accomplish (filter) with line 200 might help.


Thanks,

Brandon

Actions

This Discussion