This topic is to discuss the following lesson:
Hi Rene,
One quick question, why do you need to specify: Robocop(config)#access-list 100 deny ip any any log
when at the end of every access list there is the invisible deny command.
Any clarification would be greatly appreciated.
Thanks
P.S. Keep up the good work.
Hi Edmundo,
Adding the log keyword will show all denied packets in your console. This is useful for troubleshooting, debugging or labbing.
1 Like
So if I understand correctly we would still achieve the same results if without entering this command? And the only reason we would use this command is mostly for logging events, troubleshooting or labbing…correct?
Thanks
Yes that’s right. There is always a default deny any at the bottom. Give it a try on a Cisco IOS router…
Hey… that’s really helpful…thnx so much…keep up the good work!
Hi Rene,
Very Good document on access-list , easy to understand . There are lot of options like
established, precedence etc. Any of your post explain about these options in detail.?
Thanks,
Srini
Hi Srini,
Let’s take a look at the different IP options:
R1(config-ext-nacl)#permit ip any any ?
dscp Match packets with given dscp value
fragments Check non-initial fragments
log Log matches against this entry
log-input Log matches against this entry, including input interface
option Match packets with given IP Options value
precedence Match packets with given precedence value
reflect Create reflexive access list entry
time-range Specify a time-range
tos Match packets with given TOS value
ttl Match packets with given TTL value
DSCP refers to the DSCP value in the TOS byte:
https://networklessons.com/quality-of-service/ip-precedence-dscp-values/
Fragments refers to fragmented IP packets.
Log will show matched packets on the console (like I did in this example). Log-input does the same but also allows you to select an interface.
Option refers to the option field in the header…there are a lot of options here.
Precedence refers to the precedence value in the TOS byte:
https://networklessons.com/quality-of-service/ip-precedence-dscp-values/
Reflect is for reflexive access-lists:
https://networklessons.com/quality-of-service/ip-precedence-dscp-values/
Time-range for time-based access-lists:
https://networklessons.com/security/cisco-asa-time-based-access-list/
TOS is for some of the non-DSCP or non-precedence values that you can use in the TOS byte.
TTL is to match on a certain time-to-live value in the IP packet header.
There’s also a big list for TCP options:
R1(config-ext-nacl)#permit tcp any any ?
ack Match on the ACK bit
dscp Match packets with given dscp value
eq Match only packets on a given port number
established Match established connections
fin Match on the FIN bit
fragments Check non-initial fragments
gt Match only packets with a greater port number
log Log matches against this entry
log-input Log matches against this entry, including input interface
lt Match only packets with a lower port number
match-all Match if all specified flags are present
match-any Match if any specified flag is present
neq Match only packets not on a given port number
option Match packets with given IP Options value
precedence Match packets with given precedence value
psh Match on the PSH bit
range Match only packets in the range of port numbers
reflect Create reflexive access list entry
rst Match on the RST bit
syn Match on the SYN bit
time-range Specify a time-range
tos Match packets with given TOS value
ttl Match packets with given TTL value
urg Match on the URG bit
Some of these options refer to the IP packet (dscp, option, precedence, tos, ttl). The established is an interesting one…
Established checks TCP headers to see if the ACK bit is enabled, after the three way handshake every TCP header has the ACK bit enabled. You can create an ACL statement that only allows “established” sessions with this. We don’t use it anymore…it has been replaced by:
https://networklessons.com/security/reflexive-access-list/
https://networklessons.com/security/cisco-cbac-configuration-example/
https://networklessons.com/security/zone-based-firewall-configuration-example/
Let me know if you want to know some specific options.
Rene
1 Like
Hi Rene,
Great!. Your reply got many useful information. For doing CCNP , above mentioned links will give very good idea on access-lists topics.
Hi Rene
Robocop(config)#access-list 100 permit icmp 1.1.1.0 0.0.0.255 host 2.2.2.2 echo
Robocop(config)#access-list 100 deny ip any any
for this case, Robocop cannot ping to ED209 ip 192.168.12.1
how can i allow robocop to ping ED209 192.168.12.1
When the access-list is applied inbound on Robocop, you’ll need to permit the ICMP return traffic from ED209. Something like this:
permit icmp host 192.168.12.1 host 192.168.12.2
Or you could make it more “specific” by adding echo-reply at the end of that statement.
2 Likes
Hi Rene hope ur well geode Avond meneer ! Took CCNA today and didn’t pass unfortunately I had booked exam and I didn’t feel quite ready bit annoyed since I knew that I hadn’t practised a specific area which I now need to practice ! And this area I scored 0 per cent on the post test break down … ! I need to practice practice practice … My score was encouraging enough overall so I will go back to study after a well earned week off
Wanted to say that your e-book for CCNA has been really helpful and would recommend it to anybody especially from point of view as a technical reference point for understanding the topics ground up from a practical hands on perspective
Hi Will,
Sorry to hear you didn’t pass the exam! You now do know what the exam is like and the things that you still need to focus on, that will make it much easier the next time you attempt it. Glad to hear you like the book!
Rene
Quick question.
So if I do permit tcp any any eq telnet will that only match traffic DESTINY to port 23? IE 192.168.1.1:12345 > 4.2.2.2:23 MATCH however what about the return traffic?
4.2.2.2:23 > 192.168.1.1:12345? I’m thinking about a QoS classification where that would only match the first half of the conversation.
Does that make sense?
Hi William,
That’s correct.
If you use “permit tcp any any eq telnet” then it will only match traffic that has destination port 23. In your example, it will match 192.168.1.1:12345 > 4.2.2.2:23.
The return traffic will be 4.2.2.2:23 > 192.168.1.1:12345, the source port will be 23 and the destination port is 12345.
Rene
1 Like
So for QOS wouldn’t you want to mark both parts of the conversation and give it proper BW? How would you accomplish that without NBAR?
The answer to this depends on where traffic is flowing relative to where you have applied a QoS service-policy. If you take a simple network like this:
Client ---- Router ---- Server
Where you want to reserve bandwidth for telnet traffic from the client to the server and from the server back to the client, it would be something like this (all from the Router):
ip access-list extended ACL_TELNET-CLIENT-2-SERVER
permit tcp host <CLIENT> host <SERVER> eq 23
class-map CM_TELNET-CLIENT-2-SERVER
match access-group ACL_TELNET-CLIENT-2-SERVER
policy-map PM_TELNET-CLIENT-2-SERVER
class CM_TELNET-CLIENT-2-SERVER
bandwidth 100
Interface from Client-----> (config-if)#service-policy input PM_TELNET-CLIENT-2-SERVER
Now you just repeat the template that is above to capture the traffic coming back from the Server to the Client. The key difference will be how you write your ACL:
ip access-list extended ACL_TELNET-SERVER-2-CLIENT
permit tcp host <SERVER> eq 23 host <CLIENT>
class-map CM_TELNET-SERVER-2-CLIENT
match access-group ACL_TELNET-SERVER-2-CLIENT
policy-map PM_TELNET-SERVER-2-CLIENT
class CM_TELNET-SERVER-2-CLIENT
bandwidth 100
Interface from Server-----> (config-if)#service-policy input PM_TELNET-SERVER-2-CLIENT
1 Like
In my experience this isn’t common practice, do you guys see it? I see more like reserving bandwidth in one direction, not the return. Is that fair to say?
The safest approach is to set QoS in both directions. At my company, we are concerned with prioritizing VOIP, print jobs, and SSH. VOIP is a bit easier since the VOIP server and phones automatically mark their traffic as DSCP EF, so we just trust those markings, but with the others, we do, in fact, mark them similar to the example I provided earlier where the classifier for return trip looks to the source port, not the destination.
If you knew that your remote sites, for example, had more of a problem with downloads saturating the bandwidth than uploads, you probably could set QoS in just the one direction and be fine. We set it both ways “just in case.”
1 Like