Configuring a Cisco router as a Domain Name Service server (DNS server) - Basic Configuration

In the internet world, every host is identified by an IP address. The purpose of DNS (Domain Name 

Service) is to translate simple names than can be understood and memorized easily by us; humans, to those IP addresses since it will nearly impossible to memorize the IP address of all the websites you use.

Cisco’s IOS can act as a DNS server, of course it might not scale to big DNS servers out there, but it might come in handy in many situations.

Let’s check this topology

Let’s assume for a moment here that google.com server is attached to R4 and it has an IP address 44.44.44.44. R1 is trying to ping google.com. the configuration can be split into 2 parts.

1-      DNS server configuration

Let’s first enable DNS

DNS(config)#ip dns server

Now that we enabled DNS, we need to statically map the domain name to the ip address of google.com

    

DNS(config)#ip host google.com 44.44.44.44

let’s check our configuration so far

DNS#show hosts

Default domain is lab.local

Name/address lookup uses static mappings

Codes: UN - unknown, EX - expired, OK - OK, ?? - revalidate

       temp - temporary, perm - permanent

       NA - Not Applicable None - Not defined

Host                      Port  Flags      Age Type   Address(es)

google.com                None  (perm, OK)  0   IP    44.44.44.44

The configuration is pretty simple indeed, now let’s configure R1 to resolve host name via DNS router

2-   DNS client

First, let’s identify the name-server that we will send DNS requests to, in our case its IP address is 3.3.3.3

    

R1(config)#ip name-server 3.3.3.3

Now let’s enable name lookup ability on R1

     R1(config)#ip domain lookup

Let’s test with ping

                R1#ping google.com

Translating "google.com"...domain server (3.3.3.3) [OK]

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 44.44.44.44, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 40/42/48 ms

From the output shown above, it is clear that R1 used the DNS server 3.3.3.3 and that server replied that the host being fetched has an IP address of 44.44.44.44.

Let’s see how the DNS reacted to the request, first let’s enable the debug

DNS#debug domain

Domain Name System debugging is on

*Mar  1 00:34:34.387: DNS: Incoming UDP query (id#41532)

*Mar  1 00:34:34.387: DNS: Type 1 DNS query (id#41532) for host 'google.com' from 10.1.2.1(59224)

*Mar  1 00:34:34.391: DNS: Servicing request using view default

*Mar  1 00:34:34.391: DNS: Reply to client 10.1.2.1/59224 query A

*Mar  1 00:34:34.391: DNS: Finished processing query (id#41532) in 0.004 secs

*Mar  1 00:34:34.391: DNS: Sending response to 10.1.2.1/59224, len 44

You can see that the server identified this as a Type-1 DNS query which means that the requester needs to resolve a hostname into an IP address, other requests like Type-2 might be for an email address and so on. The DNS query number is to identify every request on it’s own, since a single host might request many addresses, this is to distinguish them from one another.

Finally after the DNS server finds the hostname, it replies to R1 with the IP address  of the desired host.

Removing the painful key-ring authentication in Ubuntu 13.10 ( Unity )

Finally, the constant paint of putting my password to the keyring over and over again every time i login with Ubuntu is over,

here are the simple steps

1- In Unity Lens , type passwords and keys

2- press the view in the menu bar, then check "by keyring"

3- a menu on the left will appear, right click on login, then change password

4- It will ask you for your old key-ring password, insert the old password and when it asks you for a new one, just leave it empty and press continue

5- Repeat step 3 for "Default" instead of "Login"

hopefully that will end your pain too

OSPF Default Route Cost

In OSPF design, STUB and NSSA areas can have multiple Area Border Routers (ABRs) to achieve redundancy or load-balancing in traffic. By default if a router in a STUB or a NSSA area is dual homed to two ABRs with equal links, and that ABR is injecting a default route into that area, the STUB router will load-balance the traffic to the ABRs. The problem occurs when those ABRs doesn’t have equal links connected to the backbone area. Even though traffic from the stub router will be load balanced to the ABRs, the traffic from the ABR with the lower bandwidth link will drop traffic going to the backbone if it exceeds the its maximum link bandwidth.

Let’s take a look at this simple topology

Area 1 has two ABRs, R2 and R10, Both are injecting a default route in Area 1. Since R7 has two Gig links to both ABRs, it will load balance traffic on those two links, which get us to an interesting concept here.

The default route is a generated route, meaning that it is originated from the ABR itself, and by default it will have a metric of 1. Meaning, even though R2 have a 155 Mb link connected to Area 0 and R10 has a 1000 Mb link to Area 0, R7 will still have the default route metric with the cost of 2 ( 1 for the link to the ABR + 1 for the generated default route cost)

Now let’s see how that looks from the prospective of R7 in normal conditions.

R7# show ip route

Gateway of last resort is 10.7.10.10 to network 0.0.0.0

     7.0.0.0/32 is subnetted, 1 subnets

C       7.7.7.7 is directly connected, Loopback0

     10.0.0.0/24 is subnetted, 2 subnets

C       10.7.10.0 is directly connected, FastEthernet0/0

C       10.2.7.0 is directly connected, FastEthernet0/1

O*IA 0.0.0.0/0 [110/2] via 10.7.10.10, 00:30:57, FastEthernet0/0

               [110/2] via 10.2.7.2, 00:27:16, FastEthernet0/1

As the routing table of R7 shows, it will load balance traffic equally to both ABRs.

Let’s see the OSPF Database from R7 Also

R7#show ip ospf database summary

            OSPF Router with ID (7.7.7.7) (Process ID 1)

                Summary Net Link States (Area 1)

  Routing Bit Set on this LSA

  LS age: 1820

  Options: (No TOS-capability, DC, Upward)

  LS Type: Summary Links(Network)

  Link State ID: 0.0.0.0 (summary Network Number)

  Advertising Router: 2.2.2.2

  LS Seq Number: 80000003

  Checksum: 0x71C2

  Length: 28

  Network Mask: /0

        TOS: 0  Metric: 1

  Routing Bit Set on this LSA

  LS age: 1461

  Options: (No TOS-capability, DC, Upward)

  LS Type: Summary Links(Network)

  Link State ID: 0.0.0.0 (summary Network Number)

  Advertising Router: 10.10.10.10

  LS Seq Number: 80000002

  Checksum: 0x8292

  Length: 28

  Network Mask: /0

        TOS: 0  Metric: 1

As mentioned earlier, this will cause R2 to drop traffic exceeding 155 Mb even though its share of traffic can reach 500 Mb.

Now that can be fixed either by increasing the cost of link towards R2, but since that I might have multiple routers in that area, and the default route is propagated to all routers in the stub area, we can use the sub area command default-cost.

The default-cost commands sets the initial metric of the default route injected in the area, it has a range from 0 to 16777215. In our case here, we can either set default-cost of R2 to any number higher than 1 or we can lower the default cost of R7 to 0

Let’s higher the default cost of R2

R2(config)#router ospf 1

R2(config-router)#area 1 default-cost 1000

Showing the router table of R7, only the default route from R10 in installed in the routing table

R7#show ip route

Gateway of last resort is 10.7.10.10 to network 0.0.0.0

     7.0.0.0/32 is subnetted, 1 subnets

C       7.7.7.7 is directly connected, Loopback0

     10.0.0.0/24 is subnetted, 2 subnets

C       10.7.10.0 is directly connected, FastEthernet0/0

C       10.2.7.0 is directly connected, FastEthernet0/1

O*IA 0.0.0.0/0 [110/2] via 10.7.10.10, 00:02:15, FastEthernet0/0

Also checking the database of R7

R7#show ip ospf database summary
            OSPF Router with ID (7.7.7.7)(ProcessID1)
                Summary Net Link States (Area 1)

  Routing Bit Set on this LSA
  LS age: 303
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(Network)
  Link State ID: 0.0.0.0 (summary Network Number)
  Advertising Router: 2.2.2.2
  LS Seq Number: 80000006
  Checksum: 0x95B0
  Length: 28
  Network Mask: /0
        TOS: 0  Metric: 1000
   
  Routing Bit Set on this LSA
  LS age: 1063
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(Network)
  Link State ID: 0.0.0.0 (summary Network Number)
  Advertising Router: 10.10.10.10
  LS Seq Number: 80000003
  Checksum: 0x8093
  Length: 28
  Network Mask: /0
        TOS: 0  Metric: 1

The route is still in the OSPF database, in case the link to R10 fails, R7 will install the other route to R2.

One thing to remember here is that for an ABR to advertise a generated default route into an area, it must have at least a single interface in area 0

If the link between R10 and backbone area fails, R7 will still prefer R10 as its gateway if R10 has it’s loopback 0 advertised in Area 0, to overcome this, you’ll have to advertise R10 Loopback 0 in area 1 so that it will not have any interfaces in area 0, but that’s a whole other debate.

Configuring Cisco Frame-Relay Switch

This Tutorial will show you how to configure a Cisco router as a Frame Relay Switch and how to use sub-interfaces to make a full mesh topology.

Zone Based Firewall (ZBFW) Video Tutorial

A video tutorial to understand and configure Zone Based Firewall ( ZBFW)

Detecting DDOS attack sources via ip source-track

One of the nightmares for corporates and service providers are DOS and DDOS attacks. DOS (Denial of Service) attacks are flooding UDP, TCP, reverse DNS or ICMP to a remote host to utilize its processor or bandwidth to bring it down or make it unreachable. DDOS (Distributed Denial of Service) has the same technique but from many different senders (sometimes hundreds of thousands) either using Net-Bots or random PCs that are infected by a virus or a Trojan, waiting for the attacker to control them and use them to send traffic to his target victim.

Sometimes DOS attacks aren't recognized immediately since the attack bandwidth is distributed among multiple links and then aggregated at the core. The problem with DOS attacks is that you can't just suddenly shutdown your internet links otherwise you just did what the attacker wanted in the first place which is bring your server/router/host down. This might be a web server, a database server or a portal to your customers, of course this is not a good thing

Several techniques has been developed in order to defend your network against DOS/DDOS, but for them to be effective, first you need to identify who is attacking your network and what is he attacking, even though the latter part is easy, the first one is really the problem, because if it’s a web-server for example, you need to differentiate the legitimate requests from the non-legitimate requests.

One way of detecting DOS/DDOS attacks are using cisco’s built in ip source-track command.

Let’s check the below topology

The attacker is initiating a DOS attack through ISP1 and there are normal users sending requests through ISP2

I’ll simulate those requests by generating traffic (ICMP messages) from both the attacker and normal users on the internet. Now let’s imagine that suddenly the server admin is facing a problem the server and you noticed that internet links towards ISP1 had a sudden rise in the bandwidth. You can clearly suspect that a DOS or a DDOS attack is being initiated towards your network.

The key here is to detect the attack from a transient node that all the internet traffic is passing through it. In our case here it’s R1, in other cases you might have 2 redundant internet routers to check the attack from.

Now let’s configure R1 to monitor transient traffic going to the victim.

          R1 (config)#ip source-track 192.168.1.1

Notice that this command is put  on a transient node since the router discretely enables Netflow on all R1 interfaces and monitors all transient  traffic going to 192.168.1.1 only.

Now let’s check to see that traffic is heading for the victim

R1#show ip source-track 192.168.1.1

Address         SrcIF          Bytes   Pkts     Bytes/s     Pkts/s

192.168.1.1     Fa0/0             11M  7886       97140         65

192.168.1.1     Fa0/1            943K  9436         695          2

Let’s hit it after a few seconds again

R1#show ip source-track 192.168.1.1

Address         SrcIF          Bytes   Pkts     Bytes/s     Pkts/s

192.168.1.1     Fa0/0             17M    12K     101469         69

192.168.1.1     Fa0/1            948K  9481         352          0

As shown above. The difference is huge in traffic between traffic entering to R1 F0/0 interface and F0/1 interface

Now let’s look at the cache in the Netflow to see the details of traffic of both interfaces

R1#show ip source-track 192.168.1.1 cache

IP packet size distribution (42060 total packets):

   1-32   64   96  128  160  192  224  256  288  320  352  384  416  448  480

   .000 .000 .000 .227 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000

    512  544  576 1024 1536 2048 2560 3072 3584 4096 4608

   .000 .000 .000 .000 .772 .000 .000 .000 .000 .000 .000

IP Flow Switching Cache, 278544 bytes

  2 active, 4094 inactive, 66 added

  1033 ager polls, 0 flow alloc failures

  Active flows timeout in 0 minutes

  Inactive flows timeout in 15 seconds

IP Sub Flow Cache, 25280 bytes

  0 active, 1024 inactive, 0 added, 0 added to flow

  0 alloc failures, 0 force free

  1 chunk, 1 chunk added

  last clearing of statistics never

Protocol         Total    Flows   Packets Bytes  Packets Active(Sec) Idle(Sec)

--------         Flows     /Sec     /Flow  /Pkt     /Sec     /Flow     /Flow

SrcIf          SrcIPaddress    DstIf          DstIPaddress    Pr TOS Flgs  Pkts

Port Msk AS                    Port Msk AS    NextHop              B/Pk  Active

Fa0/1          40.0.0.1        Null           192.168.1.1     01 00  10       4

         

SrcIf          SrcIPaddress    DstIf          DstIPaddress    Pr TOS Flgs  Pkts

Port Msk AS                    Port Msk AS    NextHop              B/Pk  Active

0000 /0  0                     0800 /0  0     0.0.0.0               100     5.4

Fa0/0          3.3.3.3         Null           192.168.1.1     01 00  10     902

0000 /0  0                     0800 /0  0     0.0.0.0              1400     9.0

From the output shown, there are two source IP addresses sending traffic to the victim, the first source is 40.0.0.1 and the second is 30.0.0.1

The difference in packet sizes is 100 bytes from 40.0.0.1 and 1400 bytes from 30.0.0.1. You can also see that 30.0.0.1 is sending almost 900 packets per second compared to 4 packets from 40.0.0.1.

Now we can see the devastating effect of the attack on the normal user experience. The pings from the normal users are starting to timeout since DOS traffic is eating all the queues with its big packets and huge bandwidth. In the real world, DDOS attack has reached a phenomenal 300 Gb\s traffic bandwidth, which for sure can congest the majority of service providers links even the big ones. You can read more about this specific attack here.

(ping output from normal user)

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!..!!..!!!.!.!..!!.!.!!!!!.!!.!.!!!!!...!!...!!!!..!!!.!!.!!.!!.....!!.!!!!..!!!...!.!!!.!!!.!!!!!!.!!.!..!....!!!!..!!.!!!!!!!!!.!...!.!.!!....!!..!!!.!.!!....!!..!!......!!..!.!!.!!!!!!!!.!!.!..!.!....!!.!..!!...!..!.!!!..!!!..!!.!...!.!!!!.!..!.!!!.!.!.!!.!.!.!..!.!!..!!.!...!!!!.!.!!!.!.!.!!.!.!.!..!.!.!!!!.!!..!!!!.!...!!!!!..!....!.!!!!!!.!.!.!!!!!.!!!!!.!..!!!!.!..!!.!..!!!.!!.!.!...

Even though this simple command won’t do you very much in case of a 300 Gb attack, but for sure it will tell you about the small or medium ones that happen on weekly basis.