This topic is to discuss the following lesson:
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.
P.S. Keep up the good work.
Adding the log keyword will show all denied packets in your console. This is useful for troubleshooting, debugging or labbing.
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?
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!
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.?
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:
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:
Reflect is for reflexive access-lists:
Time-range for time-based access-lists:
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:
Let me know if you want to know some specific options.
Great!. Your reply got many useful information. For doing CCNP , above mentioned links will give very good idea on access-lists topics.
Robocop(config)#access-list 100 permit icmp 18.104.22.168 0.0.0.255 host 22.214.171.124 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.
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
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!
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 > 126.96.36.199:23 MATCH however what about the return traffic?
188.8.131.52: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?
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 > 184.108.40.206:23.
The return traffic will be 220.127.116.11:23 > 192.168.1.1:12345, the source port will be 23 and the destination port is 12345.
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
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.”