Nov 6

URL Filtering using IOS

Posted by Radu

Today, while I was trying to keep my students awake during a CCNA1 presentation I noticed that two of them were looking at 9Gag and they ignored me. Not that I was saying something so deep and meaningful but it was a little bit frustrating for me. So, as soon I finished my presentation, I opened a console to the local router (a Cisco 2821 ) and began to filter 9gag.

Obviously you cannot do that with ACLs when you want to filter a website running on multiple addresses like 9gag. Even if you use hostname instead of an IP address, that hostname is resolved once using dns servers defined in your configuration and that’s it.

So I used a policy and five minutes later those two were the frustrated ones. This is how I did it :

!
class-map match-any URLFILTER
    match protocol http host *9gag.com
!
policy-map DROPURL
    class URLFILTER
      drop
!
!
interface FastEthernet 0/1
    desc Internal
    service-policy input DROPURL
!

And that was it. Next time, facebook, prepare your url, I wanna filter you.

Or, using CBAC (Context-Based Access Control) :

!
ip inspect name WEBFILTER http urlfilter
ip urlfilter allow-mode on
ip urlfilter exclusive-domain deny .9gag.com
!
!
interface FastEthernet 0/1
   desc Internal
   ip inspect WEBFILTER in
!

Oh, and if you’re wondering how to do url filtering with linux the answer is “it’s complicated”. You need either a proxy (squid, privoxy) or, if you are shameless, you can do it using DNS hijacking.

Sep 27

ccie topology

Posted by Marius Bunget

For those who want to prepare for advanced certification, you can use topology CCIE R&S. You can download the dynamips/gns3 topology here. I use c3725 platform running AdvancedIPServices image.

May 30

CCNAS REVIEW

Posted by Marius Bunget

You are not allowed to remove any configurations, only to modify them. In order for an exercise to be validated by the moderator all configuration errors must be detected and solved accordingly.

Challenge

Topology

You can download the dynamips topology here

task6

The following commands must be functional:

  • R1: ping 10.0.34.4 source 1.1.1.1

Attention: The traffic must be encrypted and R2 must do NAT

Hint: Use Wireshark and the dynagen functionality offered to capture packets .

May 29

CCNA REVIEW

Posted by Marius Bunget

For all challenges you are not allowed to remove any configurations, only to modify them. In order for an exercise to be validated by the moderator all configuration errors must be detected and solved accordingly.

Challenge 1

Topology

You can download the dynamips topology here

task1

You are allowed to modify configurations only on R2!

The following commands must be functional:

  • R1: ping 4.4.4.4
  • R1: telnet 4.4.4.4

Challenge 2

Topology

You can download the dynamips topology here

task2

The following commands must be functional:

  • R1: ping 10.0.14.4

Challenge 3

Topology

You can download the dynamips topology here

topology

The following commands must be functional:

  • R1: ping 10.0.14.4
  • R1: ping 10.0.34.4
  • R4: ping 10.0.14.1
  • R4: ping 10.0.12.1

Challenge 4

Topology

You can download the dynamips topology here

Untitled

The following commands must be functional:

  • R1: ping 4.4.4.4 source 1.1.1.1

Challenge 5

Topology

You can download the dynamips topology here

task5

The following commands must be functional:

  • R1: ping 3.3.3.3
  • R1: ping 4.4.4.4
  • R2: ping 4.4.4.4 source 2.2.2.2
May 9

Private VLANs

Posted by Marius Bunget

PVLANs provide layer 2 isolation between ports within the same broadcast domain. There are three types of PVLAN ports:

  • Promiscuous— A promiscuous port can communicate with all interfaces, including the isolated and community ports within a PVLAN.
  • Isolated— An isolated port has complete Layer 2 separation from the other ports within the same PVLAN, but not from the promiscuous ports. PVLANs block all traffic to isolated ports except traffic from promiscuous ports. Traffic from an isolated port is forwarded only to promiscuous ports.
  • Community— Community ports communicate among themselves and with promiscuous ports. These interfaces are separated at Layer 2 from all other interfaces in other communities or isolated ports within their PVLAN.

IP Addressing
All the members of the Private VLAN can share a common IP Space where the IP space is assigned to the Primary VLAN. The hosts connected to isolated or community ports can have the addresses assigned from the address space of the Primary VLAN.

pvlan

Steps to Configure Private VLAN

1. Set VTP mode to transparent
2. Create Primary and Secondary VLANs
3. Map secondary VLANs to Primary VLANs
3. Configure ports in Secondary VLANs and assign VLAN memberships
4. Configure Promiscuous ports and map them to primary-secondary VLAN pairs

Configuration:

Switches S1 and S2  must be configured as follows:

Create vlans 101 and 102 and then associate them to the primary Vlan 100.

vlan 100
  private-vlan primary
  private-vlan association 101-102
!
vlan 101
  private-vlan community
!
vlan 102
  private-vlan community

On S1:

interface FastEthernet0/1
 switchport private-vlan mapping 100 101-102
 switchport mode private-vlan promiscuous
!
interface FastEthernet0/3
 switchport private-vlan host-association 100 101
 switchport mode private-vlan host
!
interface FastEthernet0/5
 switchport private-vlan host-association 100 102
 switchport mode private-vlan host
!
interface FastEthernet0/13
 switchport trunk encapsulation dot1q
 switchport mode trunk

On S2:
interface GigabitEthernet0/4
 switchport private-vlan host-association 100 101
 switchport mode private-vlan host
!
interface GigabitEthernet0/6
 switchport private-vlan host-association 100 102
 switchport mode private-vlan host
!
interface GigabitEthernet0/13
 switchport trunk encapsulation dot1q
 switchport mode trunk
Mar 30

Securing a router or a switch involves not only filtering traffic with ACLs, but also means securing the device itself. Creating users with certain privilege levels is an important first step.  This can be done on a device by device basis or using a centralized authentication server. In any case, it involves using AAA (Authentication, Authorization and Accounting).

If using a centralized system for user authentication, the router or switch would be an authentication client. It will need to communicate with a server using a specialized protocol. Two such protocols are wide known: TACACS, a Cisco proprietary protocol and RADIUS, an open standard protocol. In a Cisco-centered  network, IOS authentication would work with Cisco’s ACS (Access Control Server), but in some cases , specially for lab purposes, ACS could be harder to get an setup.

A very quick way to setup an authentication server is to use FreeRADIUS, an open source server that uses the RADIUS protocol. It can be easily installed on a Linux box and used with minimum configurations. Here are the steps to setup:

Install the packet:

root@radiusserver# apt-get install freeradius

Add each client (router or switch) in the /etc/freeradius/clients.conf file. Each client is identified by its hostname and requires a password (secret).

root@radiusserver# vim /etc/freeradius/clients.conf

Client 192.168.0.2
{
secret = authentications3cr3t
shortname = ClientRouter

}

Add each user that is allowed on the device.

root@radiusserver# vim /etc/freeradius/users.conf

iosuser Cleartext-Password := “icanhazroot”
DEFAULT Auth-Type := Reject

Start or restart the FreeRADIUS server:

root@radiusserver# /etc/init.d/freeradius restart

On the client side (the network device), AAA needs to be enabled, the RADIUS server configured and then the authentication need to be set to use an external server.

ClientRouter(config)# aaa new-model
ClientRouter(config)# radius-server host $RADIUS_SERVER_IP auth 1812 acct 1813 key authentications3cr3t
ClientRouter(config)# aaa authentication login default group radius

This is a basic configuration of a FreeRADIUS server, but it can also provide features like LDAP intergration.

Mar 27

IP CEF

Posted by Marius Bunget

CEF load balancing is based on a combination of source and destination packet information. It allows you to optimize resources by distributing traffic over multiple paths for transferring data to a destination. You can configure load balancing on a per-destination or per-packet basis. Load balancing decisions are made on the outbound interface. When you configure load balancing, configure it on outbound interfaces.

Per-destination load balancing allows the router to use multiple paths to achieve load sharing. Packets for a given source-destination host pair are guaranteed to take the same path, even if multiple paths are available. Traffic destined for different pairs tend to take different paths. Per-destination load balancing is enabled by default when you enable CEF.

To determine if CEF is enabled globally on a router, use the commands show ip cef and show ipv6 cef. If it is not enabled by default, you can turn it on globally using the command ip cef for IPv4. To enable CEF for IPv6, first enable CEF for IPv4, then use the command ipv6 cef. You can verify that CEF is enabled on an interface using the commands show cef interface {interface} and show ipv6 cef {interface} detail.

Topology

ip cef

The routing table of router R2 is similar to R1:

R1#show ip route

[...]

C    192.168.12.0/24 is directly connected, FastEthernet0/0
1.0.0.0/24 is subnetted, 1 subnets
C       1.1.1.0 is directly connected, Loopback1
2.0.0.0/24 is subnetted, 1 subnets
S       2.2.2.0 [1/0] via 192.168.21.2
[1/0] via 192.168.12.2
C    192.168.21.0/24 is directly connected, FastEthernet1/0

Check if CEF is enabled and show the forwarding information base (FIB) with information obtained from the routing table.

R1#show ip cef
Prefix                    Next Hop                    Interface
0.0.0.0/0           drop                              Null0 (default route handler entry)
0.0.0.0/32         receive
1.1.1.0/24           attached                      Loopback1
1.1.1.0/32           receive
1.1.1.1/32            receive
1.1.1.255/32       receive
2.2.2.0/24           192.168.21.2            FastEthernet1/0
192.168.12.2            FastEthernet0/0

[...]

Routers with default configuration perform Load Sharing per destination, also known as Fast Switching. Fast switching is the default IOS switching mode in some routers. The debug ip packet command displays process packets.

R1#debug ip packet
IP packet debugging is on
R1#ping 2.2.2.2 repeat 1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 56/56/56 ms
R1#
*Mar  1 00:39:40.379: IP: tableid=0, s=192.168.12.1 (local), d=2.2.2.2 (FastEthernet1/0), routed via FIB
*Mar  1 00:39:40.379: IP: s=192.168.12.1 (local), d=2.2.2.2 (FastEthernet1/0), len 100, sending
*Mar  1 00:39:40.431: IP: tableid=0, s=2.2.2.2 (FastEthernet0/0), d=192.168.12.1 (FastEthernet0/0), routed via RIB
*Mar  1 00:39:40.431: IP: s=2.2.2.2 (FastEthernet0/0), d=192.168.12.1 (FastEthernet0/0), len 100, rcvd 3
R1#ping 2.2.2.2 repeat 1 so
R1#ping 2.2.2.2 repeat 1 source loo 1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 56/56/56 ms
R1#
*Mar  1 00:39:48.411: IP: tableid=0, s=1.1.1.1 (local), d=2.2.2.2 (FastEthernet0/0), routed via FIB
*Mar  1 00:39:48.411: IP: s=1.1.1.1 (local), d=2.2.2.2 (FastEthernet0/0), len 100, sending
*Mar  1 00:39:48.467: IP: tableid=0, s=2.2.2.2 (FastEthernet1/0), d=1.1.1.1 (Loopback1), routed via RIB
*Mar  1 00:39:48.467: IP: s=2.2.2.2 (FastEthernet1/0), d=1.1.1.1, len 100, rcvd 4

Note that for different source-destination pairs the outbound interface changes.

Per packet Load Sharing configuration.

R1(config)#int f 0/0
R1(config-if)#no ip route-cache    //enable process switching
R1(config-if)#ip load-sharing per-packet
R1(config-if)#exit
R1(config)#int f 1/0
R1(config-if)#no ip route-cache
R1(config-if)#ip load-sharing per-packet
R1(config-if)#exit

R1#sh cef interface fastEthernet 0/0
[...]
Per packet load-sharing is enabled
[...]
Fast switching type 1, interface type 18
IP CEF switching disabled

Verify per packet Load Sharing:

R1#ping 2.2.2.2 source loopback 1 repeat 3

Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!
Success rate is 100 percent (3/3), round-trip min/avg/max = 16/37/52 ms
R1#
*Mar  1 01:00:35.419: IP: tableid=0, s=1.1.1.1 (local), d=2.2.2.2 (FastEthernet1/0), routed via FIB
*Mar  1 01:00:35.419: IP: s=1.1.1.1 (local), d=2.2.2.2 (FastEthernet1/0), len 100, sending
!
*Mar  1 01:00:35.467: IP: tableid=0, s=1.1.1.1 (local), d=2.2.2.2 (FastEthernet0/0), routed via FIB
*Mar  1 01:00:35.467: IP: s=1.1.1.1 (local), d=2.2.2.2 (FastEthernet0/0), len 100, sending
!
*Mar  1 01:00:35.523: IP: tableid=0, s=1.1.1.1 (local), d=2.2.2.2 (FastEthernet1/0), routed via FIB
*Mar  1 01:00:35.523: IP: s=1.1.1.1 (local), d=2.2.2.2 (FastEthernet1/0), len 100, sending

When CEF is disabled all the packets are processed by the Routing Information Base (RIB) as shown below:

R1(config)#no ip cef
R1(config)#exit
R1#clear ip cef * prefix-statistics
R1#clear ip cef 2.2.2.2 prefix-statistics
R1#ping 2.2.2.2 source loopback 1 repeat 2
Type escape sequence to abort.
Sending 2, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!
Success rate is 100 percent (2/2), round-trip min/avg/max = 28/56/84 ms
*Mar  1 01:07:07.475: IP: tableid=0, s=1.1.1.1 (local), d=2.2.2.2 (FastEthernet0/0), routed via RIB
*Mar  1 01:07:07.475: IP: s=1.1.1.1 (local), d=2.2.2.2 (FastEthernet0/0), len 100, sending
!
*Mar  1 01:07:07.507: IP: tableid=0, s=1.1.1.1 (local), d=2.2.2.2 (FastEthernet1/0), routed via RIB
*Mar  1 01:07:07.507: IP: s=1.1.1.1 (local), d=2.2.2.2 (FastEthernet1/0), len 100, sending

Dec 30

IOS + Linux = Quagga

Posted by Alex Juncu

Cisco IOS’s shell is a popular interface for devices in the networking world. But also in the network world, there are a lot of Linux/Open Source fans. The Quagga open source project tries to bring together IOS and Linux, by providing an IOS-like interface for configuring Linux’s interfaces, routing table and firewall, along side its own implementations of RIP, OSPF and BGP daemons.

The Quagga Software Routing Suite comes as a set of daemos. The main one is the zerbra daemon (Zebra is the old name of the project). This core daemon does the interaction with the Linux kernel and, also, with other daemons like ripd (RIP daemon), ospfd (OSPF daemon), bgpd (BGP daoemon). Quagga is modular, so you can implement new protocols if needed via a standard API.

To configure Quagga, you first need to start the daemons (at least the core one), in the /etc/quagga/daemons file. Each daemon has its own configuration file (ex. /etc/quagga/zebra.conf, /etc/quagga/ripd.conf etc.). Accessing the IOS-like shell is done via the vtysh command. Once in this shell, most commands available in Cisco’s IOS are available.

Router / # cd
Router ~ # vtysh

Hello, this is Quagga (version 0.99.18).
Copyright 1996-2005 Kunihiro Ishiguro, et al.

Router# conf t
Router(config)# hostname  LinuxRouter
LinuxRouter(config)# exit
LinuxRouter# show ?
bgp             BGP information
clns            clns network information
daemons         Show list of running daemons
debugging       State of each debugging option

[...]

Keep in mind that some things are not 100% identical to a Cisco router (ex. the interface names). Here’s an example of how to configure an interface.

LinuxRouter# conf t
LinuxRouter(config)# interface  eth0
LinuxRouter(config-if)# ip address  141.85.42.1 ?
A.B.C.D/M  IP address (e.g. 10.0.0.1/8)
LinuxRouter(config-if)# ip address  141.85.42.1/24
LinuxRouter(config-if)# link-detect

Monitor output (show commands) are similar aside some Linux specific details (ex. Kernel routes are available in Linux, but not in IOS).

Router# sh ip route
Codes: K – kernel route, C – connected, S – static, R – RIP, O – OSPF,
I – ISIS, B – BGP, > – selected route, * – FIB route

K * 0.0.0.0/0 via 192.0.2.1, venet0 inactive
O 10.10.12.0/24 [110/10] is directly connected, eth0, 00:03:41
C>* 10.10.12.0/24 is directly connected, eth0
O 10.10.14.0/24 [110/10] is directly connected, eth1, 00:03:36
C>* 10.10.14.0/24 is directly connected, eth1
O>* 10.10.23.0/24 [110/20] via 10.10.12.2, eth0, 00:02:46
O>* 10.10.24.0/24 [110/20] via 10.10.12.2, eth0, 00:02:14
*via 10.10.14.4, eth1, 00:02:14
O>* 10.10.25.0/24 [110/20] via 10.10.12.2, eth0, 00:02:41
O>* 10.10.35.0/24 [110/30] via 10.10.12.2, eth0, 00:01:21
* via 10.10.14.4, eth1, 00:01:21
O>* 10.10.45.0/24 [110/20] via 10.10.14.4, eth1, 00:02:08
C>* 127.0.0.0/8 is directly connected, lo
C>* 127.0.0.1/32 is directly connected, venet0
C>* 172.10.10.0/32 is directly connected, venet0
K>* 192.0.2.1/32 is directly connected, venet0

Configuring a routing protocol instance is also similar:

LinuxRouter# conf t
LinuxRouter(config)# router ospf
LinuxRouter(config-router)# network  192.168.123.0/0 area 0

As you can see, coming from an IOS background, this tool is very easy to use on your Linux box. It is far from perfect since it doesn’t have the years in production like IOS or iproute2, but it is cool to test out.

Dec 13

Unlike Linux’s iptables, Cisco’s filtering via Access Control Lists sometimes has hidden behavior.

Let us test how ACL filtering works using the following topology. We assume that we have Layer 3 connectivity via static routes. We will apply ACLs on the outbound direction of F1/0 on R2 (we want it to be somewhere in the path from R1 to R3)

3r

With no ACLs applied anywhere, all traffic will flow.

R1#ping 3.3.3.3 source 1.1.1.1
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent

Let’s start with the basics and make a classic standard access list that denies R1’s loopback.

R2(config)#access-list 42 deny host 1.1.1.1
R2(config)#int f1/0
R2(config-if)#ip access-group 42 out

The loopback on R1 is blocked…

R1#ping 3.3.3.3 source 1.1.1.1
U.U.U
Success rate is 0 percent (0/5)

… but so is any other traffic that goes out of R2’s F1/0.

R1#ping 3.3.3.3 source F0/0
U.U.U
Success rate is 0 percent (0/5)

The first rule of Cisco’s ACLs is that there is an implicit deny (ip) all (all) rule at the end of every ACL. But this is not visible anywhere. You have to know it.

R2#sh access-lists
Standard IP access list 42
10 deny   1.1.1.1 (8 matches)
Extended IP access list BLOCK_HTTP

But if that ACL is empty? What if you apply an access list that does not contain any rules (was not declared)?

R2(config)#int f1/0
R2(config-if)#ip access-group 28 out
R2(config-if)#do sh access-lists
Standard IP access list 42
10 deny   1.1.1.1 (8 matches)
Extended IP access list BLOCK_HTTP

R1#ping 3.3.3.3 source 1.1.1.1

Type escape sequence to abort.
!!!!!
Success rate is 100 percent

Traffic passes. The inexistent ACL applied on an interface is ignored. But this is because you can’t have an empty classical (numbered) ACL. What if you do the same thing with a named ACL?

R2(config)#ip access-list standard EMPTY_ACL
R2(config-std-nacl)#exit
R2(config)#do sh ip access-list
Standard IP access list 42
10 deny   1.1.1.1 (8 matches)
Standard IP access list EMPTY_ACL
Extended IP access list BLOCK_HTTP
R2(config)#int f1/0
R2(config-if)#ip access-group EMPTY_ACL out

R1#ping 3.3.3.3 source 1.1.1.1

Type escape sequence to abort.
!!!!!
Success rate is 100 percent

Traffic is still not filtered. So, the rule is that a empty (inexistant or deleted)  ACL is ignored by the interface filter.

One more ACL applied on R2 with a deny all rule (no traffic should pass out of F1/0).

R2(config)#ip access-list standard DENY_ALL_ACL
R2(config-std-nacl)#deny any
R2(config-std-nacl)#do sh ip access
Standard IP access list 42
10 deny   1.1.1.1 (8 matches)
Standard IP access list DENY_ALL_ACL
10 deny   any (8 matches)
Standard IP access list EMPTY_ACL
10 deny   any (8 matches)
Extended IP access list BLOCK_HTTP
R2(config-std-nacl)#int f1/0
R2(config-if)#ip access-group DENY_ALL_ACL out

Ping form R1 is filtered.

R1#ping 3.3.3.3 source 1.1.1.1
Packet sent with a source address of 1.1.1.1
U.U.U
Success rate is 0 percent (0/5)

Since no traffic should go out the interface, a ping from R2 to R3 should also fail, yet it doesn’t.

R2#ping 3.3.3.3
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/20/44 ms

As a final rule, traffic generated by a router is never filtered by an ACL applied any interface of that router.

Jul 18

Scenario:
You have two routers running RIP, but the two routers aren’t directly connected because there is a third router between them. See topology below. How do you get routes across because RIP only communicates with routers that are directly connected?
riplab

The simple answer is to create a GRE tunnel between R1 and R3 so a tun interface simulates a direct connection of the two routers. But let’s take a more didactic approach to remember some things about RIP.

RIP v2 sends the updates to the address 224.0.0.9 that is a local multicast address (TTL=1).  But there is another, very important in some situations (like some Frame Relay networks), way to send routes, and that is via unicast to a statically configured neighbor. Configuration is done via the neighbor command in the router rip configuration.  The routes will be encapsulated in normal IP unicast packets and since RIP runs on top of UDP, they should be routed as any other packet.

R1:

interface Serial0/0/1
ip address 10.1.2.1 255.255.255.0
interface Loopback 0
ip address 192.168.0.1 255.255.255.0
router rip
version 2
passive-interface Loopback0
network 10.0.0.0
network 192.168.0.0

neighbor 10.2.3.3
no auto-summary

R3:

interface Serial0/0/1
ip address 10.2.3.3 255.255.255.0
interface Loopback 0
ip address 172.16.0.1 255.255.255.0
router rip
version 2
passive-interface Loopback0
network 10.0.0.0
network 172.16.0.0
neighbor 10.1.2.1
no auto-summary

You still need to have a network command for the interfaces when you send and receive the updates (in this case 10.0.0.0) otherwise the received updates will be ignored.

First thing you should be careful of is the fact that R1 and R3 need layer3 communication. So you do need static routes for the R1 and R3 routers through R2.

Having connectivity between each other, the router starts sending unicast packets with the routes. debug ip rip would show the following:

RIP: sending v2 update to 10.1.2.1 via Serial0/0/1 (10.2.3.3)
RIP: build update entries
172.16.0.0/24 via 0.0.0.0, metric 1, tag 0

Notice the update is sent to an unicast address and not 224.0.0.9.

Routes are received but they still are not in the routing tables. debug ip rip shows why:

RIP: ignored v2 update from bad source 10.2.3.3 on Serial0/0/1

This reminds us of how RIP works: if a router receives an update it checks to see if the source of the packet is on the same subnet as the IP configured on the interface. If they don’t match, the update is ignored. In our case, the source of the updates are not on the same network because R2 does not modify the packet source/destination in any way.

The solution to this is to disable the default mechanism with the no validate-update-source command in the router rip configuration. This way any updates will be accepted.

Here is a wanted route in the routing table of R3:

R    192.168.0.0/24 [120/1] via 10.1.2.1, 00:00:27

Notice that the next hop is not directly connected so it need to do a recursive lookup and use the static route to send it to R2 first.

S       10.1.2.1/32 [1/0] via 10.2.3.2