cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
933
Views
29
Helpful
22
Replies

ACL bloking eBGP Session

visitor68
Level 4
Level 4

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

22 Replies 22

Edison Ortiz
Hall of Fame
Hall of Fame

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.

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

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

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?

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

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....?

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

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

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

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

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

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

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??

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

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco