Cisco: How to use reflexive access-list and why they are useful

Reflexive access-list are one of the method that help us achive firewall functionality with a router hardware. The other methods that serve to the same purpose are Context-Based Access Control (CBAC) and TCP Intercept. For an introduction to CBAC with example please check my older post Cisco: Use CBAC to achieve firewall functionality on router device . For TCP Intercept check my blog in the next weeks.

Today, I will present Reflexive access-list and how can take advantage of their specific behavior. Reflexive access list commands are used to configure IP session filtering. IP session filtering provides the ability to filter IP packets based on upper-layer protocol “session” information. They are generally used to allow outbound traffic and to limit inbound traffic in response to sessions that originate inside the router. E.g. you want to allow a TCP connection from outside only is the initall packet was send from the inside. Take FTP active mode session on data port TCP 20. If you are doing FTP from inside the LAN port 20 will be allowed outbound and also inbound. But if somebody from outside try to reach one device on your LAN on port 20, the session will be dropped due to Access-list implemenation.

Reflexive ACLs can be defined only with extended named IP ACLs. They cannot be defined with numbered or standard named IP ACLs, or with other protocol ACLs. Reflexive ACLs can be used in conjunction with other standard and static extended ACLs. As a syntax Reflexive access-list are presented exactly like any normal ACL, with the implementation of two parameters “reflect” and “evaluate”.

Let have a look to this example topology. R2 will be the router where the Reflexive ACL has to be implemented.  The implementation is quite simple. You configure an outbound access-list which permit tcp sessions from any subnet to any subnet. The difference from this outbound ACL and a normal one, will be the “reflect” parameter at the end on the permit line. The “reflect” parameter will have the name OUT (it can be any name you want).

After the outbound list is completed configured, then we will configure an inbound access-list with a “permit tcp any any” statement followed by the parameter “evaluate OUT”. Below it’s a simple example how to configure this Reflexive ACL on the topology presented above, to permit UDP and TCP inside only if the session was initiated from inside:

ip access-list extended OUTBOUND
permit tcp any any reflect TO_REFLECT
permit udp any any reflect TO_REFLECT

ip access-list extended INBOUND
evaluate TO_REFLECT

interface Serial1/0
ip access-group OUTBOUND out
ip access-group INBOUND in

So, the INBOUND ACL will evaluate OUTBOUND ACL to permit or deny TCP packet from outside. Remember that by default, packets generated by the router itself will not be
reflected. This is why if you have a routing protocol running towards outside,  on your router you have to permit static those packets.  Let’t take the example of the BGP routing protocol. Assume that you have a BGP peering between R2 and R3. On R2 you will have to permit static the BGP packets from outside, like in the example below:

ip access-list extended OUTBOUND
permit tcp any any reflect TO_REFLECT
permit udp any any reflect TO_REFLECT

ip access-list extended INBOUND
permit tcp any any eq bgp
permit tcp any eq bgp any
evaluate TO_REFLECT

interface Serial1/0
ip access-group OUTBOUND out
ip access-group INBOUND in

In this way the BGP packets local generated on the router, will be allowed IN and OUT on the WAN interface. You will proceed in the same way for other packets that are generated on  the router and you want to allow them to pass through WAN interface.

For a live example please see the video presentation below. If you did not had a look to the example topology, now it would be a good time to do it. Already I have preconfigured BGP AS 300 on router R3 and BGP AS100 on R2 and R1, so the conectivity from R1 to R3 is not a problem. Also R1 and R3 have a  Loopback interface which is advertised into BGP. After implementing the Reflexive ACL on R2 I will be allow to telnet from R1 to R3, but not viceversa. Also the BGP packets between R2 and R3 will be static permited in ACL.


I hope that I could helped you to understand the importance on the Reflexive ACL. Sometime simple ACL would do the job and then I would suggest not to complicate things. But if you have something tricky to solve regarding access in your LAN, or you prepare for some exam like CCIE, then Reflexive ACL are quite useful and important.

7 reasons why MPLS has been wildly successful

The IETF Thursday threw a birthday party for one of its most successful standards: Multi-Protocol Label Switching.

The Internet’s leading standards body hosted a panel discussion outlining the reasons why the 12-year-old protocol has been so widely deployed and such a big moneymaker for carriers.

“MPLS is one of our wildly successful protocol suites,” said Loa Andersson, co-chair of the IETF’s MPLS Working Group and the principal networking architect at the Swedish Research Institute, Acreo AB. Andersson served as moderator for the panel, which was hosted by the Internet Architecture Board, a sister organization to the IETF.

Here are the seven reasons why MPLS has proven so popular:

1. MPLS embraced IP

2. MPLS is flexible

3. MPLS is protocol neutral

4. MPLS is pragmatic

5. MPLS is adaptable

6. MPLS supports metrics

7. MPLS scales

Read the full article on

Cisco certification: Important content change in CCIE Voice Lab Exam

This announcement is from The Cisco Learning Network:

Effective July 16th, 2009, important content changes will be implemented in the CCIE Voice Lab Exam. Candidates for lab exams scheduled July 16th, 2009 or later should prepare using the v3.0 Lab Equipment and Software Versions. Candidates scheduled on or before July 15th, 2009 should continue using the v2.0 Lab Equipment and Software Versions.

You can examine the v3.0 CCIE Voice Lab print below:

1.00 Implement and Troubleshoot Campus Infrastructure and Services
1.01 VLAN
1.02 DHCP
1.03 TFTP
1.04 NTP
2.00 Implement and Troubleshoot CUCM Endpoints
2.01 CUCM SCCP Endpoints
2.02 CUCM SIP Endpoints
3.00 Implement and Troubleshoot CUCME Endpoints
3.01 CUCME SCCP Endpoints
3.02 CUCME SIP Endpoints
4.00 Implement and Troubleshoot Voice Gateways
4.01 T1/E1 PRI
4.02 T1/E1 CAS
4.03 H.323
4.04 MGCP
4.05 SIP
4.06 H.323 RAS
4.07 IP-IP Gateway/CUBE
5.00 Implement and Troubleshoot Call Routing Policies
5.01 Route Patterns and Dial-peers
5.02 Digit Manipulations and Translations
5.03 Class of Services
5.04 Route Selection Preference and Redundancy
5.05 Mobility and Single Number Reach
6.00 Implement and Troubleshoot High Availability Features
6.01 SRST
6.02 AAR
7.00 Implement and Troubleshoot Media Resources
7.01 CODEC Selection and Flexibility
7.02 Conference Bridges
7.03 Transcoder
7.04 Music-on-hold
7.05 Media Resources Preference and Redundancy
7.06 Other CUCM Media Resources
8.00 Implement and Troubleshoot Supplementary Services
8.01 Call Park
8.02 Call Pickup
8.03 Barge
8.04 Callback
8.05 Other Supplementary Services
9.00 Implement and Troubleshoot Other CUCM Voice Applications
9.01 Extension Mobility
9.02 IPMA
9.03 Other CUCM Voice Applications
10.00 Implement and Troubleshoot QoS and CAC
10.01 L2/L3 Traffic Classifications and Policing
10.02 L2/L3 Queuing Mechanisms
10.03 L2 LFI
10.04 RSVP
10.05 Call Admission Control
11.00 Implement and Troubleshoot Messaging
11.01 Cisco Unity Connection
11.02 Cisco Unity Express
11.03 Call Handling and Routing
12.00 Implement and Troubleshoot Cisco Unified Contact Center Express
12.01 Advanced Configuration
12.02 Script Customization
12.03 Redundancy
13.00 Implement and Troubleshoot Cisco Unified Presence
13.01 CUCM Presence
13.02 Cisco Unified Presence Server Integration

Please

IETF to explore new routing technique

ietf-logoThe IETF is forming a new working group to address scalability issues in the Internet’s routing system caused by companies splitting their network traffic over multiple carriers, a practice called multihoming.

The new working group will build upon a base proposal from a team of Cisco engineers to create a new tunneling mechanism that will be used by the Internet’s edge and core routers.

The new mechanism — dubbed LISP for Locator/Identifier Separation Protocol — is designed to reduce the number of entries in the routing tables stored in the core routers operated by ISPs.

LISP logically separates a block of IP addresses that a company advertises out to the global Internet via its edge routers into two functions: one for identifying the systems using the IP addresses, and the other for locating where these systems connect to the Internet. This separation allows LISP to aggregate the location information, so less of it needs to be stored in the core routers.

Read the full article on