admin

MS SQL Backup with Python and pyodbc

 MS SQL, Programming, Python  2 Responses »
Sep 262012
 

Hello readers, i have been in a situation where i wanted to take backup from a MS SQL database through the network and i didnt have any clue about it, so is started digging the internet for a solution, which came up quickly at “ryan’s tech blog” link on how to actually take the backup, after this i realised that there were multiple databases and i want all of them, of course these databases created/deleted at will so the next problem was how to get the complete list of the current databases in the instance, so i came up with the below 2 functions using the pyodbc module.

The Concept:
There is a windows server with MS SQL installed and file sharing enabled.
There is a windows client in the network which connects to MS SQL though “trusted connection” AKA no user/password needed to connect to database because this is handled by the windows authentication mechanism, and also it has mounted a network drive from the windows server’s shared folder.

The Procedure:
The windows client connects to the Database and takes the databases list, then it commands the database to take backup to a local directory, then take the backup data through netword drive and copy them wherever you want.

The Code:

# imports
import pyodbc

# define the backup paths
server_backup_path = 'c:\\mssql_backup\\'
client_backup_path = 'z:\\mssql_backup\\'

# Connection object (notice that i dont include the database name)
conn = pyodbc.connect('DRIVER={SQL Server};SERVER=SERVER\\DATAINSTANCE;Trusted_Connection=yes', autocommit=True)

# List databases function
def list_databases(conn_obj):
  dbs = []
  cur = conn_obj.cursor()
  result = cur.execute('SELECT name from sysdatabases').fetchall()
  cur.close()
  for db in result:
    dbs.append(db[0])
  return dbs

# backup database function, please notice that the function gets 2 paths, one from the server's point of view
# and one from the clients point of view aka network drive
def backup_db(conn_obj, db_name, server_backup_path, client_backup_path):
  try:
    # you need to remove the previous file because it just appends the information every time you run the
    # backup function, i am using try/except because the first time the file doesnt exist.
    os.remove(client_backup_path + db_name + r'_sql.bak')
  except:
    print db_name + ' doesnt exist yet...'
  cur = conn_obj.cursor()
  try:
    # here i am using try/except because some system databases cant be backed up such as tempdb or 
    # a database might be problematic for any reason, perhaps an exclude mechanism is better, its
    # up to you.
    cur.execute('BACKUP DATABASE ? TO DISK=?', [db_name, server_backup_path + db_name + r'_sql.bak'])
    while cur.nextset(): 
      pass
    cur.close()
  except:
    print 'cant backup: ' + db_name

# take the list
dbs = list_databases(conn)

# take backup for each database
for db in dbs:
  backup_db(conn, db, server_backup_path, client_backup_path)

# close the connection
conn.close()

Now you have all your files at the mssql_backup directory and you can copy the file wherever you want. I hope this will be help other with the same problems out there. Ofcourse i am not a professional python developer, so i will be very glad to hear from you any improvements to my code 🙂

See you soon!

Debian Squeeze apache2 mod_security’s REQBODY_ERROR

 Linux  No Responses »
Jul 122012
 

Hello, last night i tried to install mod_security on a debian squeeze server, at first i thought that it would be an easy task but i was wrong, it turned out quite tricky to get it running the main reason was that debian has version 2.5.12-1 at its repository which it is not support the latest Core Rule Set so if you too are seeing this error:

Syntax error on line 91 of /etc/apache2/modsecurity_crs/activated_rules/modsecurity_crs_20_protocol_violations.conf:
Error creating rule: Unknown variable: REQBODY_ERROR
Action 'configtest' failed.
The Apache error log may have more information.
 failed!

You are lucky,there is a bugfix, go to the mentioned line of apache’s error and change 

REQBODY_ERROR

with 

REQBODY_PROCESSOR_ERROR

solution was given here https://lists.owasp.org/pipermail/owasp-modsecurity-core-rule-set/2011-May/000779.html

if you are not feeling well with this for whatever reason, you can always use the outdated CRS that it comes with the package from the debian repository and it is located at /usr/share/doc/mod-security-common/examples/rules

root@debian ~ # ls -la /usr/share/doc/mod-security-common/examples/rules
total 92K
drwxr-xr-x 5 root root 4.0K Jul 11 23:27 .
drwxr-xr-x 3 root root 4.0K Jul 11 23:27 ..
drwxr-xr-x 2 root root 4.0K Jul 11 23:27 base_rules
-rw-r--r-- 1 root root  22K Feb  5  2010 CHANGELOG
-rw-r--r-- 1 root root  18K Jul 31  2009 LICENSE
-rw-r--r-- 1 root root 6.6K Feb  5  2010 modsecurity_crs_10_config.conf
drwxr-xr-x 2 root root 4.0K Jul 11 23:27 optional_rules
-rw-r--r-- 1 root root  17K Feb  5  2010 README
drwxr-xr-x 2 root root 4.0K Jul 11 23:27 util

Hope this helps somebody to avoid much time going from site to site

Get remote user’s IP address using Flask

 Python  2 Responses »
Jul 122012
 

This is a simple function to get remote user’s IP address using Flask’s request_object. It is very simple and takes a lot of tweaks, like reading also the X-Forwarded-For field from received header for users who use proxies.

dependencies:

from flask import request

function:

def get_ip():
  # get creative here!
  return request.remote_addr

Whats my ip service

 Uncategorized  No Responses »
Jul 112012
 

I have published a small script that tells you your IP, it is useful for scripting purposes you can check it out
here

Installing TP-LINK TL-WN727N USB Wireless N 150Mbps Adapter on Debian Squeeze

 Debian, Linux  22 Responses »
Feb 122012
 

Lets start with the product, TP-LINK L-WN727N is a USB Wireless N Adapter, and it has 150Mbps throughput on 802.11n Wireless Networks, it uses the RT5370 Chipset from Ralink (Link). The price from a local store here in Greece is 8 Euros, which makes this adapter very attractive low-cost solution. You can read more on product’s specification page here

This thing was tough… it took me almost 10 hours of posts reading, downloads, installs, builds to find a clean and easy solution to make it work, but first i must thank the VirtualBox for its support, without it the procedure of installing/cloning would have took me more than 24 hours.

I think that the problem mainly caused by the kernel hardware support of Debian Squeeze which is too old to support this chipset because the same adapter works out of the box on Debian Wheezy which is currently in testing stage with newer kernel (3.2.5), but i dont like the idea of working on test releases. Anyway, The result is tested with latest Debian Squeeze 6.0.4-i386 installation.

Step 1: Gather The files

First we need the drivers which fortunately are available through chipset maker’s Ralink website, i have downloaded from this url the latest drivers which currently are the version 2.5.0.3, The downloaded filename is 2011_0719_RT3070_RT3370_RT5370_RT5372_Linux_STA_V2.5.0.3_DPO.bz2 which is wrong and it needs to be renamed to 2011_0719_RT3070_RT3370_RT5370_RT5372_Linux_STA_V2.5.0.3_DPO.tar.bz2 because it really is a tar archive compressed with bzip2.

Step 2: Compile and install the driver

After you have obtained the drivers file, put it in your box and do the following in order to uncompress/compile/install the driver:

root@debian:~# tar jxvf 2011_0719_RT3070_RT3370_RT5370_RT5372_Linux_STA_V2.5.0.3_DPO.tar.bz2
root@debian:~# cd 2011_0719_RT3070_RT3370_RT5370_RT5372_Linux_STA_V2.5.0.3_DPO
root@debian:~/2011_0719_RT3070_RT3370_RT5370_RT5372_Linux_STA_V2.5.0.3_DPO# make
root@debian:~/2011_0719_RT3070_RT3370_RT5370_RT5372_Linux_STA_V2.5.0.3_DPO# make install

Next, Download and install latest non-free ralink firmwares:

root@debian:~# wget http://ftp.gr.debian.org/debian/pool/non-free/f/firmware-nonfree/firmware-ralink_0.35_all.deb
root@debian:~# dpkg -i firmware-ralink_0.35_all.deb

Now if everything finished without errors you are ready to plug in your usb adapter, and verify that the system “see” it and has loaded the needed modules, in my situation the output was:

root@debian:~# dmesg
<----- TEXT OMMITED ----->

[   51.276088] usb 1-2: new full speed USB device using ohci_hcd and address 3
[   51.951155] usb 1-2: New USB device found, idVendor=148f, idProduct=5370
[   51.951159] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[   51.951162] usb 1-2: Product: 802.11 n WLAN
[   51.951163] usb 1-2: Manufacturer: TPlink
[   51.951165] usb 1-2: SerialNumber: 1.0
[   51.953625] usb 1-2: configuration #1 chosen from 1 choice
[   52.046122] rtusb init rt2870 --->
[   52.046354]
[   52.046354]
[   52.046355] === pAd = e1ec6000, size = 517232 ===
[   52.046356]
[   52.047306] <-- RTMPAllocTxRxRingMemory, Status=0
[   52.047409] <-- RTMPAllocAdapterBlock, Status=0
[   52.054416] usbcore: registered new interface driver rt2870

root@debian:~# lsusb | grep 5370
Bus 001 Device 003: ID 148f:5370 Ralink Technology, Corp. RT5370 Wireless Adapter

root@debian:~# lsmod | grep 5370
rt5370sta             575832  0
usbcore                99329  5 rt5370sta,usbhid,ohci_hcd,ehci_hcd

Step 3: Configure WPA/PSK and Automatic activation on startup.

The created network device name is ra0, Ralink's driver doesnt need the help of wpasupplicant in order to join WPA/PSK networks, it has its own way to do this. After you plugged in the USB Adapter, the module dynamically created a configuration file for the adapter and stored in as /etc/Wireless/RT2870STA/RT2870STA.dat, now open it with your favorite editor and change the values below to match your setup:

SSID=<your-ssid>
AuthMode=WPAPSK
EncrypType=TKIP
WPAPSK=<your wpa password>

If you want to start the wireless connection on system's startup, just add the below lines to your /etc/network/interfaces file:

auto ra0
iface ra0 inet dhcp

If you dont, add only the below line in your /etc/network/interfaces file:

iface ra0 inet dhcp

Now, you can "pull up" your connection manually from command line with the command:

root@debian:~# ifup ra0

or just reboot your machine to test it.

Thats it, i hope this guide will help some people out there who bought the same device or similar with the same chipset and trying to figure out how to use it in current Debian's stable release at least until Wheezy goes stable and this guide will get obsolete

OpenBSD: IPv6 Over IPv4 GRE Tunnel to Cisco Router

 Cisco, IPv6, Networks, Open Source, OpenBSD  1 Response »
Aug 302011
 

Here i am again, my server was down for some days because i moved to another location and now its back up and running.

On this move to the new location i realized that they dont have IPv6 in their network, at first i was thinking to implement Dual Stack IPv6 on their Cisco router but unfortunately the router there doesnt support IPv6, it needs IOS upgrade and i cant disrupt the traffic to reboot for such reason, so eventually i forgot this idea and thought that a GRE tunnel over IPv4 would be a good solution to my problem for some time until the upgrade of the Cisco router.

Topology Information:

Cisco WAN IP: 192.168.0.1
OpenBSD WAN IP: 172.16.0.1

Cisco Router Configuration

interface tun0
description IPv6_Over_IPv4_GRE
ipv6 address 2001:1::1/126
tunnel source 192.168.0.1
tunnel destination 172.16.0.1

OpenBSD Host Configuration

Enable GRE tunnel.

basilisk:~# sysctl net.inet.gre.allow=1
basilisk:~# sysctl net.inet.gre.wccp=1

Create the interface.

basilisk:~# ifconfig gre0 create

Assign IPv6 address to the new interface

basilisk:~# ifconfig gre0 inet6 2001:1::2/126

Tell the GRE tunnel where to connect

basilisk:~# ifconfig gre0 tunnel 172.16.0.1 192.168.0.1

Activate the tunnel

basilisk:~# ifconfig gre0 link1 up

Add default gateway for the IPv6 traffic

basilisk:~# route -n add -inet6 default 2001:1::1

And at last verify IPv6 connectivity

basilisk:~# ping6 -c 4 ipv6.google.com
PING6(56=40+8+8 bytes) 2001:1::1 --> 2a00:1450:8007::63
16 bytes from 2a00:1450:8007::63, icmp_seq=0 hlim=54 time=70.275 ms
16 bytes from 2a00:1450:8007::63, icmp_seq=1 hlim=54 time=66.095 ms
16 bytes from 2a00:1450:8007::63, icmp_seq=2 hlim=54 time=66.804 ms
16 bytes from 2a00:1450:8007::63, icmp_seq=3 hlim=54 time=66.031 ms

--- ipv6.l.google.com ping6 statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 66.031/67.301/70.275/1.743 ms

Now that all worked as expected you can make this configuration persistent.

Enable GRE at boot.

basilisk:~# echo "net.inet.gre.allow=1" >> /etc/sysctl.conf
basilisk:~# echo "net.inet.gre.wccp=1" >> /etc/sysctl.conf

My interface’s configuration file looks like this:

basilisk:~# more /etc/hostname.gre0
inet6 2001:1::2/126
tunnel 172.16.0.1 192.168.0.1
link1 up
!route -n add -inet6 default 2001:1::1

You may now reboot and verify that you can ping IPv6 addresses

IPv4/IPv6 Dual Stack BGP Configuration: Part 3 – BiRD

 IPv6, Linux, Networks, Open Source  4 Responses »
Jul 292011
 

Hello again this is the third and the last post of a series of posts about simple configuration examples implementing IPv4/IPv6 Dual Stack BGP on Open Source Routing platforms. Previous posts dealt with similar configuration for OpenBGPD and Quagga, this time we will touch a little the BiRD Dynamic Routing Platform.

BiRD
BiRD “was developed as a school project at Faculty of Math and Physics, Charles University Prague.” as its webpage says. It isnt very well known, but in my search of alternatives for routing it came to my attention many times, but its configuration complexity made me to avoid it. So the time has come with this lab, its my first time configuring this deamon and i must say that i was very excited while playing with this software, it is awesome, it took me some time to figure out its configuration philosophy, but once i had it, all the others aspects was straight forward. I found this routing platform very flexible and advanced with very high amount of configuration options. The next time that i will use linux as a router i will give BiRD a try to production and i believe it will give me back my favor.

Ok, now lets go to the lab informations:

ISP router details:

AS: 1000

IPv4 network: 10.0.0.0/8

IPv6 network: fc00::/32

Peering Interface: f0/2

Peering address IPv4: 10.0.0.5/30

Peering address IPv6: fc00::1:5/126

BiRD router details:

AS: 200

IPv4 network: 192.168.8.0/21

IPv6 network: fc00:2::/32

Peering Interface: eth0

Peering address IPv4: 10.0.0.6/30

Peering address IPv6: fc00::1:6/126

You can install BiRD via aptitude on Debian, BiRD’s author made 2 different versions of the daemon, one for IPv4 and one for IPv6 so if we want to have dual stack with this daemon we need to configure 2 files which are /etc/bird.conf and /etc/bird6.conf respectively.

Installation of BiRD on Debian:

root@debian:~# apt-get install bird6

Linux by default doesnt forwards network traffic, so we must turn forwarding on for both IPv4 and IPv6 on our server this can be done with the following 2 commands on the shell:

root@debian-quagga:~# sysctl net.ipv4.ip_forward=1
net.ipv4.ip_forward = 1
root@debian-quagga:~# sysctl net.ipv6.conf.all.forwarding=1
net.ipv6.conf.all.forwarding = 1

If you want to turn forwarding on at boot time you must change the above configuration on /etc/sysctl.com like mine’s below:

root@debian-quagga:~# cat /etc/sysctl.conf
...
...
# Uncomment the next line to enable packet forwarding for IPv4
net.ipv4.ip_forward=1

# Uncomment the next line to enable packet forwarding for IPv6
#  Enabling this option disables Stateless Address Autoconfiguration
#  based on Router Advertisements for this host
net.ipv6.conf.all.forwarding=1
...
...

No lets head to BiRD’s configuration :


root@debian-bird:~# more /etc/bird.conf
# Logging to Syslog
log syslog all;

# Route ID
router id 10.0.0.6;

# How fast scans for interfaces
protocol device {
        scan time 10;
}

# Export routes to kernel
protocol kernel {
        export all;
        scan time 15;
}

# "Pull UP" Route for BGP
protocol static static_bgp {
        import all;

        route 192.168.8.0/21 reject;
}

# BGP Configuration
protocol bgp {
        import all;
        export where proto = "static_bgp";

        local as 200;
        neighbor 10.0.0.5 as 1000;
}


root@debian-bird:~# more /etc/bird6.conf
log syslog all;

listen bgp v6only;

router id 11.11.11.11;

protocol device {
        scan time 10;
}

protocol kernel {
        export all;
        scan time 15;
}

protocol static static_bgp {
        import all;

        route fc00:2::/32 reject;
}

protocol bgp {
        import all;
        export where proto = "static_bgp";

        local as 200;
        neighbor fc00::1:5 as 1000;
        source address fc00::1:6;
}

Now lets start the processes:

root@debian-bird:~# invoke-rc.d bird start
root@debian-bird:~# invoke-rc.d bird6 start

And verify:
For IPv4 we will use the birdc client:

root@debian-bird:~# birdc
BIRD 1.2.5 ready.
bird>

if we want to check our neighbor BiRD gives as a bunch of information

bird> show protocols all bgp1
name     proto    table    state  since       info
bgp1     BGP      master   up     22:58       Established
  Preference:     100
  Input filter:   ACCEPT
  Output filter:  
  Routes:         3 imported, 1 exported, 3 preferred
  Route change stats:     received   rejected   filtered    ignored   accepted
    Import updates:              3          0          0          0          3
    Import withdraws:            0          0        ---          0          0
    Export updates:              4          3          0        ---          1
    Export withdraws:            0        ---        ---        ---          0
  BGP state:          Established
    Session:          external
    Neighbor AS:      1000
    Neighbor ID:      10.0.1.1
    Neighbor address: 10.0.0.5
    Nexthop address:  10.0.0.5
    Source address:   10.0.0.6
    Neighbor caps:    refresh
    Hold timer:       108/180
    Keepalive timer:  34/60

Show routes in RIB from BGP

bird> show route protocol bgp1
10.0.0.0/8         via 10.0.0.5 on eth0 [bgp1 22:58] * (100) [AS1000i]
192.168.0.0/21     via 10.0.0.5 on eth0 [bgp1 22:58] * (100) [AS100i]
192.168.16.0/21    via 10.0.0.5 on eth0 [bgp1 22:58] * (100) [AS300i]

Show route exported to kernel, then based on kernel’s weight of the protocol they are inserted into FIB

bird> show route export kernel1
10.0.0.0/8         via 10.0.0.5 on eth0 [bgp1 22:58] * (100) [AS1000i]
192.168.0.0/21     via 10.0.0.5 on eth0 [bgp1 22:58] * (100) [AS100i]
192.168.8.0/21     unreachable [static_bgp 22:58] * (200)
192.168.16.0/21    via 10.0.0.5 on eth0 [bgp1 22:58] * (100) [AS300i]

For IPv6 we will use the birdc6 client:

root@debian-bird:~# birdc6
BIRD 1.2.5 ready.
bird>

Show BGP Neighbord status:

bird> show protocols all bgp1
name     proto    table    state  since       info
bgp1     BGP      master   up     22:58       Established
  Preference:     100
  Input filter:   ACCEPT
  Output filter:  
  Routes:         3 imported, 1 exported, 3 preferred
  Route change stats:     received   rejected   filtered    ignored   accepted
    Import updates:              3          0          0          0          3
    Import withdraws:            0          0        ---          0          0
    Export updates:              4          3          0        ---          1
    Export withdraws:            0        ---        ---        ---          0
  BGP state:          Established
    Session:          external
    Neighbor AS:      1000
    Neighbor ID:      10.0.1.1
    Neighbor address: fc00::1:5
    Nexthop address:  fc00::1:5
    Source address:   fc00::1:6
    Neighbor caps:    refresh
    Hold timer:       91/180
    Keepalive timer:  59/60

Show routes in RIB from BGP

bird> show route protocol bgp1
fc00::/32          via fc00::1:5 on eth0 [bgp1 22:58] * (100) [AS1000i]
fc00:1::/32        via fc00::1:5 on eth0 [bgp1 22:58] * (100) [AS100i]
fc00:3::/32        via fc00::1:5 on eth0 [bgp1 22:58] * (100) [AS300i]

Show routes exported to kernel, then based on kernel’s weight of the protocol they are inserted into FIB.

bird> show route export kernel1
fc00::/32          via fc00::1:5 on eth0 [bgp1 22:58] * (100) [AS1000i]
fc00:1::/32        via fc00::1:5 on eth0 [bgp1 22:58] * (100) [AS100i]
fc00:2::/32        unreachable [static_bgp 22:58] * (200)
fc00:3::/32        via fc00::1:5 on eth0 [bgp1 22:58] * (100) [AS300i]

This was the minimum configuration for BiRD, i think this daemon has a lot of potentials it seems to be very stable if you think that major IXP like DE-CIX, LINX and more use BiRD for their heavy loaded BGP Route Server who has some thousands of BGP Peerings. Keep up the good work guys at BiRD team.

Please feel free to contact me with anything about BiRD, like success stories etc, and ofcourse point me out my mistakes but please stay calm its my first time with this beast 🙂

IPv4/IPv6 Dual Stack BGP Configuration: Part 2 – Quagga

 IPv6, Linux, Networks, Open Source  2 Responses »
Jul 262011
 

This is the second part of the simple configuration examples implementing IPv4/IPv6 Dual Stack BGP on Open Source Routing platforms. On the first post we had deal with the configuration of OpenBGPD on OpenBSD box, now its time for Linux and particulary its oldest routing daemon Quagga configured on Debian.

Quagga

Quagga is the oldest dynamic routing suite available on Linux today, it supports IPv6 and it has Cisco IOS-like interface that makes it the most attractive solution for those coming from a Cisco background like me, myself tried quagga as my first open source router also, but Quagga is like any old man, it can do some things well but its instability makes you very fraustated, some may argue on this but whenever i have tried it on real world scernarios with Multihoming and/or Multipath it failed all the times to get the uptime counter more than 1 month.

Enough with opinions, lets go straight to our lab information:

ISP router details:

AS: 1000

IPv4 network: 10.0.0.0/8

IPv6 network: fc00::/32

Peering Interface: f0/1

Peering address IPv4: 10.0.0.9/30

Peering address IPv6: fc00::1:9/126

Quagga router details:

AS: 300

IPv4 network: 192.168.16.0/21

IPv6 network: fc00:3::/32

Peering Interface: eth0

Peering address IPv4: 10.0.0.10/30

Peering address IPv6: fc00::1:A/126

The configuration of quagga for BGP spans in multiple files located /etc/quagga, but wait a minute, you said above that quagga has a cisco ios-like interface, yes, it has but we must first prepare our system to run the “vty” shell…

First of all we must install Quagga using apt-get

root@debian:~# apt-get install quagga
Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
  snmpd
The following NEW packages will be installed:
  quagga
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 1,721 kB of archives.
After this operation, 6,283 kB of additional disk space will be used.
Get:1 http://security.debian.org/ squeeze/updates/main quagga amd64 0.99.17-2+squeeze2 [1,721 kB]
Fetched 1,721 kB in 3s (561 kB/s)
Preconfiguring packages ...
Selecting previously deselected package quagga.
(Reading database ... 24324 files and directories currently installed.)
Unpacking quagga (from .../quagga_0.99.17-2+squeeze2_amd64.deb) ...
Processing triggers for man-db ...
Setting up quagga (0.99.17-2+squeeze2) ...
Loading capability module if not yet done.
Starting Quagga daemons (prio:10):.

Yeah!, is started lets verify…

root@debian:~# ps aux | grep quagga
root@debian:~#

Huh? where is its process?
Well, you are running too fast boy… first we have to declare on quagga which of its daemon we are going to use this is done simply by editing the /etc/quagga/daemons file, we need zebra daemon which is the base daemon of quagga and bgp daemon for our lab so my /etc/quagga/daemons file looks like this:

root@debian-quagga:~# cat /etc/quagga/daemons
# This file tells the quagga package which daemons to start.
#
# Entries are in the format: =(yes|no|priority)
#   0, "no"  = disabled
#   1, "yes" = highest priority
#   2 .. 10  = lower priorities
# Read /usr/share/doc/quagga/README.Debian for details.
#
# Sample configurations for these daemons can be found in
# /usr/share/doc/quagga/examples/.
#
...
...
...
zebra=yes
bgpd=yes
...
...

Linux by default doesnt forwards network traffic, so we must turn forwarding on for both IPv4 and IPv6 on our server this can be done with the following 2 commands on the shell:

root@debian-quagga:~# sysctl net.ipv4.ip_forward=1
net.ipv4.ip_forward = 1
root@debian-quagga:~# sysctl net.ipv6.conf.all.forwarding=1
net.ipv6.conf.all.forwarding = 1

If you want to turn forwarding on at boot time you must change the above configuration on /etc/sysctl.com like mine’s below:

root@debian-quagga:~# cat /etc/sysctl.conf
...
...
# Uncomment the next line to enable packet forwarding for IPv4
net.ipv4.ip_forward=1

# Uncomment the next line to enable packet forwarding for IPv6
#  Enabling this option disables Stateless Address Autoconfiguration
#  based on Router Advertisements for this host
net.ipv6.conf.all.forwarding=1
...
...

Now we can start Quagga with the following command:

root@debian-quagga:~# invoke-rc.d quagga start
Loading capability module if not yet done.
Starting Quagga daemons (prio:10): zebra bgpd.

Aha! now its says what came up, zebra and bgpd and now we can type the vtysh command to connect to the ios-like interface

root@debian-quagga:~# vtysh

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

debian-quagga# sh run
Building configuration...

Current configuration:
!
!
interface eth2
 ipv6 nd suppress-ra
!
interface lo
!
router bgp 300
 bgp router-id 10.0.0.10
 network 192.168.16.0/21
 neighbor 10.0.0.9 remote-as 1000
 neighbor 10.0.0.9 soft-reconfiguration inbound
 neighbor fc00::1:9 remote-as 1000
!
 address-family ipv6
 network fc00:3::/32
 neighbor fc00::1:9 activate
 exit-address-family
!
ip forwarding
ipv6 forwarding
!
line vty
!

Once you have complete your configuration, you can “write” your changes to startup config 😉

debian-quagga# wr
Building Configuration...
Configuration saved to /etc/quagga/zebra.conf
Configuration saved to /etc/quagga/bgpd.conf
[OK]

Now lets verify our configuration:

First lets see our neigbors, their uptime and number of prefixes learned via them.
(Notice the bug on received prefixes of IPv6 neighbor, dont get confused later on command “show ipv6 route bgp” we will see that we have “learned” the IPv6 routes.)

debian-quagga# sh ip bgp summary
BGP router identifier 10.0.0.10, local AS number 300
RIB entries 7, using 672 bytes of memory
Peers 2, using 9120 bytes of memory

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.0.0.9        4  1000      24      21        0    0    0 00:17:09        3
fc00::1:9       4  1000      24      21        0    0    0 00:17:05        0

Total number of neighbors 2

Show IPv4 routes that they are in the RIB

debian-quagga# sh ip bgp
BGP table version is 0, local router ID is 10.0.0.10
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 10.0.0.0         10.0.0.9                 0             0 1000 i
*> 192.168.0.0/21   10.0.0.9                               0 1000 100 i
*> 192.168.8.0/21   10.0.0.9                               0 1000 200 i
*> 192.168.16.0/21  0.0.0.0                  0         32768 i

Total number of prefixes 4

Show IPv6 routes that they are in the RIB

debian-quagga# sh ipv6  bgp
BGP table version is 0, local router ID is 10.0.0.10
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> fc00::/32        fc00::1:9                0             0 1000 i
*> fc00:1::/32      fc00::1:9                              0 1000 100 i
*> fc00:2::/32      fc00::1:9                              0 1000 200 i
*> fc00:3::/32      ::                       0         32768 i

Total number of prefixes 4

Now lets take a look at the IPv4 BGP routes in the FIB

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

B>* 10.0.0.0/8 [20/0] via 10.0.0.9, eth0, 00:15:05
B>* 192.168.0.0/21 [20/0] via 10.0.0.9, eth0, 00:15:05
B>* 192.168.8.0/21 [20/0] via 10.0.0.9, eth0, 00:15:05

The same for IPv6

debian-quagga# sh ipv6 route bgp
Codes: K - kernel route, C - connected, S - static, R - RIPng, O - OSPFv3,
       I - ISIS, B - BGP, * - FIB route.

B>* fc00::/32 [20/0] via fe80::c000:bff:fe6c:10, eth0, 00:16:10
B>* fc00:1::/32 [20/0] via fe80::c000:bff:fe6c:10, eth0, 00:16:10
B>* fc00:2::/32 [20/0] via fe80::c000:bff:fe6c:10, eth0, 00:16:10

And we are done on setting Dual Stack with Linux and Quagga, even on this simple lab, quagga has issues like the “show ip bgp summary” command, but to be fair, it can do very well on simple scenarios, i am using it on some very simple, production deployments and it works like a charm, but try to get away from quagga on enterprise networks.

Thanks for your time reading my 2nd article on Dual Stacking Open Source Routing Platforms please feel free to drop me comments or dm on twitter about any mistake i have done.

IPv4/IPv6 Dual Stack BGP Configuration: Part 1 – OpenBGPD

 IPv6, Networks, Open Source, OpenBSD  6 Responses »
Jul 232011
 

This is my first post and also the first post of a series that it deals with simple configuration examples on implementing IPv4/IPv6 Dual Stack BGP on Open Source Routing platforms, these configurations are only the basics to help you get Dual Stack up on your network. The post have the intention of giving informations on how to configure OpenBGPD. I will not explain tha basics of OpenBSD’s networking like installation or interface configuration etc, i will just give you the complete solution to get it running, maybe later i will make a post about these basics but i think the official FAQ is enough.

OpenBGPD

In my opinion OpenBSD with OpenBGPD and/or OpenOSPFD is the most rock-solid stable open source solution out there but this ofcourse is my point of view, both stable and easy to use, and it comes with the world’s best man pages, so use this only as starting point if you man bgpd.conf all configuration options are there very clear, if you dont see a feature on this man page then OpenBGPD doesnt support the feature at all, this is the cost to stay stable i think. I am running a number of production servers with OpenBSD and OpenBGPD but i dont use Dual Stack yet so i havent tested such configuration in the real world.

Lets go straight to lab informations.

ISP router details:

AS: 1000

IPv4 network: 10.0.0.0/8

IPv6 network: fc00::/32

Peering Interface: f0/1

Peering address IPv4: 10.0.0.1/30

Peering address IPv6: fc00::1:1/126

OpenBGPD router details:

AS: 100

IPv4 network: 192.168.0.0/21

IPv6 network: fc00:1::/32

Peering Interface: em0

Peering address IPv4: 10.0.0.2/30

Peering address IPv6: fc00::1:2/126

The configuration of OpenBGPD to announce our networks and learn our ISP’s networks is as follow:

# cat /etc/bgpd.conf
# Global configuration
AS 100
router-id 10.0.0.2

# Our Address Space
network 192.168.0.0/21
network fc00:1::/32

# IPv4 Peers
neighbor 10.0.0.1 {
        remote-as       1000
        descr           UpstreamIPv4
        local-address   10.0.0.2
        announce        IPv4 unicast
}

# IPv6 Peers
neighbor fc00::1:1 {
        remote-as       1000
        descr           UpstreamIPv6
        local-address   fc00::1:2
        announce        IPv6 unicast
}

OpenBSD by default doesnt forwards traffic so we have to turn on forwarding for IPv4 and IPv6 this can be done from the console with the following commands:

# sysctl net.inet.ip.forwarding=1
net.inet.ip.forwarding: 1 -> 1
# sysctl net.inet6.ip6.forwarding=1
net.inet6.ip6.forwarding: 1 -> 1

if you want to start forwarding at boot you must change the above values on /etc/sysctl.conf as shown below.

#       $OpenBSD: sysctl.conf,v 1.49 2011/02/16 10:37:45 mikeb Exp $
#
# This file contains a list of sysctl options the user wants set at
# boot time.  See sysctl(3) and sysctl(8) for more information on
# the many available variables.
#
net.inet.ip.forwarding=1        # 1=Permit forwarding (routing) of IPv4 packets
#net.inet.ip.mforwarding=1      # 1=Permit forwarding (routing) of IPv4 multicast packets
#net.inet.ip.multipath=1        # 1=Enable IP multipath routing
#net.inet.icmp.rediraccept=1    # 1=Accept ICMP redirects
#net.inet6.icmp6.rediraccept=0  # 0=Don't accept IPv6 ICMP redirects
net.inet6.ip6.forwarding=1      # 1=Permit forwarding (routing) of IPv6 packets
#net.inet6.ip6.mforwarding=1    # 1=Permit forwarding (routing) of IPv6 multicast packets
#net.inet6.ip6.multipath=1      # 1=Enable IPv6 multipath routing
#net.inet6.ip6.accept_rtadv=1   # 1=Permit IPv6 autoconf (forwarding must be 0)
...
...
...

Next we need to start BGP daemon, this can be done from console with the following command:

# bgpd

if you want to start bgpd at boot you must change the below line on the file /etc/rc.local

# more /etc/rc.conf | grep bgpd
bgpd_flags=""           # for normal use: ""

Verify Commands:

# bgpctl show
Neighbor                   AS    MsgRcvd    MsgSent  OutQ Up/Down  State/PrfRcvd
UpstreamIPv6             1000          8          3     0 00:00:28      4
UpstreamIPv4             1000          8          3     0 00:00:28      4

shows us our neighbors their uptime and received prefixes numbers.

# bgpctl show rib
flags: * = Valid, > = Selected, I = via IBGP, A = Announced
origin: i = IGP, e = EGP, ? = Incomplete

flags destination          gateway          lpref   med aspath origin
*>    10.0.0.0/8           10.0.0.1           100     0 1000 i
AI*>  192.168.0.0/21       0.0.0.0            100     0 i
      192.168.0.0/21       10.0.0.1           100     0 1000 100 i
*>    192.168.8.0/21       10.0.0.1           100     0 1000 200 i
*>    192.168.16.0/21      10.0.0.1           100     0 1000 300 i
*>    fc00::/32            fc00::1:1          100     0 1000 i
AI*>  fc00:1::/32          ::                 100     0 i
      fc00:1::/32          fc00::1:1          100     0 1000 100 i
*>    fc00:2::/32          fc00::1:1          100     0 1000 200 i
*>    fc00:3::/32          fc00::1:1          100     0 1000 300 i

shows us all routes received from our neigbors and they are added to our RIB it also shows our announced prefixes.

# bgpctl show fib bgp
flags: * = valid, B = BGP, C = Connected, S = Static
       N = BGP Nexthop reachable via this route
       r = reject route, b = blackhole route

flags prio destination          gateway
*B      48 10.0.0.0/8           10.0.0.1
*B      48 192.168.8.0/21       10.0.0.1
*B      48 192.168.16.0/21      10.0.0.1
*B      48 fc00::/32            fc00::1:1
*B      48 fc00:2::/32          fc00::1:1
*B      48 fc00:3::/32          fc00::1:1

show us routes selected from bgp daemon and they are placed to the kernel’s routing table or Forwarding Table.

Thats all for OpenBGPD configuration, i am not an OpenBGPD or OpenBSD master so i will be very glad to receive feedback from you about any mistakes i have done in this post or recommendations.