MIPS vs ARM的比較(從網路整理的資料)

 X R3v Z a+~/}{ B
[正文]6k | o&}9h J%i R
1.流水線結構 pipeline%Z A&[1j |0O
　　- MIPS 是最簡單的體系結構之一，所以使大學喜歡選擇 MIPS 體系結構來介紹計算體系結構課程。 ar t-R U O4H)D
　　- ARM has barrel shifter n&\/Y | [5k9m
　　　　shifter是兩面性的，一方面它可以提高數學邏輯運算速度，另一方面它也增加了硬體的複雜性。所以和可以完成同樣功能的adder/shift register相比，效率更高，但是也佔用更多的晶片面積。
　　　　
　　- MIPS have "branch delay slot" and "load delay slot"
　　　　MIPS使用編譯器來解決上面的兩個問題。因為MIPS最初的設計思想就是使用簡單的RISC硬體，然後靠編譯器及其他軟體技術，來達成RISC的完整概念。 ]'K P N @ g M _ l
w m @,|%A5B;l0Z
2.指令結構 instruction
　　- MIPS have 32bit and 64bit architecture,but ARM only have 32bit architectureX B | E q
　　　 ARM11 局部64位元
　　- MIPS是開放式的架構,用戶可以在開發的內核中加入自己的指令， h a d h ]
　　- ARM has 4-bit condition code in every instruction
　　　ARM 在這一點很像x86。MIPS在MIPS IV也加入"conditional move"指令，來提高pipeline的效率。
　　- ARM has pre- and post-increment addressing modes
　　　　auto-increment/decrement on load/store instructions
　　- 在節省代碼空間方面，MIPS16 很類似ARM Thumb \(W K S s a i g,{

3.寄存器 register V8t2g j#j9W
　　-由於MIPS內核中有32個註冊器（Register），而ARM只有16個，這種結構設計上的先天優勢，決定了在同等性能表現下，MIPS的晶片面積和功耗會更小。2b T n:X6c1}9v'j _z K
　　- ARM 有一組特殊用途寄存器cp0-cp15,可以使用MCR,MRC等指令控制;相對應的，MIPS也有cp0 0-30,使用mfc0,mtc0 指令控制。
L d!F8N | d K,V p
　　- Register banking in ARM.　r8-r12 FIQ mode;r13:SP r14:LR Y p&O*s2Z"p0P,K
　　　 感覺不出banked register有什麼好處。
　　- MIPS has a hard-wired-to-zero register ,but ARM not ` S H(s5h }+A
　　　 MIPS use register $0 for Zero

4.位址空間 address space,];J*W6D*zJ0R1B
　　- MIPS 起始位址是0xbfc00000,會有4Mbyte的大小限制，但一般MIPS晶片都會採取一些方法解決這個問題。 H x/Z$d N S-_;[
　　　ARM沒有這種問題。)T r(Z4Y0L#P D u m }-J
　　　MIPS24K 起始位址改到了0xbf000000,現在有16Mbyte的空間了。
　　- MIPS don't have to turn paging on to enable the cache.6]#v-I ?0f T&n
　　　　MIPS have the address space for both cache and un-cache+u O:c v-N @
　　　　but ARM need enable/disable cache+M w O Z L K8c3Q I-D Y6L
r,a(M:Z7b m
5.功能 function ` D"~ a N V)t y P
　　- Float point: MIPS64 has./Q.h u!v)m6_%^*` y j
　　　　ARM's support for FP is limited, and usually not included, and it is a 32 bit architecture
　　- ARM use JTAG,MIPS use EJTAG。Debug工具一般兩種都支援。使用起來感覺差不多。
n \ Wr/{ c n:P d K
6.性能 performance \+z8i"Z T K b w
　　- 具體性能比較，因為差異性太大，所以很難分出誰好誰壞。從個人經驗來講 MIPS4k和ARM9基本上是同一個級別的,但ARM9性能似乎要比MIPS4K好。 p2v/j N*K+{"N'f
　　　同樣是32bit的MIPS24K性能上比MIPS4K有很大提升，也應該比ARM9要好些。 V O ^ [7K c#p&f g.M
　　　因為沒有用過ARM11和MIPS34K的晶片，沒法比較，但感覺這兩個似乎是一個級別的。,s F z t8v Z4_.D$Q
2s b F g B$M#t
7.應用
　　- 在1000MHz以上的應用,很難找到採用ARM架構的產品。!e {.\'K k
　　　MIPS架構用在200MHz或者是266MHz以下的應用比較少,而這恰恰是ARM的主攻市場。
　　- ARM 在手機等可擕式領域,MIPS 在住宅閘道、線纜數據機、線纜機上盒等
　　- ARM 採用硬核授權;MIPS 採用軟核授權，使用者可以自己配置，做自己的產品。;g U6G d'~ P x5g$p O a `

8.未來發展
　　- ARM的下一代走向多內核結構，而MIPS公司的下一代核心則轉向硬體多執行緒功能(multithreading)
　　　MIPS 的multithreading 很類似Intel 的 HyperThreading技術。從現在的發展來看，多內核占上風。

9.總結(U C i$D8o2h b
　　自己感覺ARM和MIPS在一開始的RISC的設計上有很多不同，但隨著技術的發展，各自揚長避短，好的技術大家都會使用。比如ARM11和MIPS R1000就使用了很多一樣的技術。感覺RISC做到了極至就都一樣了。

OpenSIPs

reference website:
http://www.nsterom.org/tech/2012/05/01/opensource_viop_system_build_a/

http://www.docin.com/p-154358866.html

[RedHat EL 5] gdm configuration.

How to setup gdm in RH el 5.

main config files: custom.conf / Default

RemoteDesktopPreference.png: 執行 vino-preferences 的 diagram,這跟執行下列 command 是一樣的
[ ]# gconftool-2 -s -t bool /desktop/gnome/remote_access/prompt_enabled true    
; 設定在 VNC Viewer 要輸入 Password
[ ]# gconftool-2 -s -t bool /desktop/gnome/remote_access/prompt_enabled false    
; 設定在 VNC Viewer 不需要輸入 Password
[ ]# gconftool-2 -g /desktop/gnome/remote_access/prompt_enabled                     
; 取得上述設定值

開啟或關閉 SELinux

OSWikiHK，自由中文開源知識庫

Jump to: navigation, search

[编辑]

CentOS/Fedora/RedHat 的 /etc/sysconfig/selinux

在新版本中的 Red Hat 和 Fedora 上，修改檔案 /etc/sysconfig/selinux:

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#       enforcing - SELinux security policy is enforced.
#       permissive - SELinux prints warnings instead of enforcing.
#       disabled - SELinux is fully disabled.
SELINUX=enforcing

# SELINUXTYPE= type of policy in use. Possible values are:
#       targeted - Only targeted network daemons are protected.
#       strict - Full SELinux protection.
SELINUXTYPE=targeted

把 SELINUX 設定為 disable, 下次啟動系統後將會停止 SElinux。

[编辑]

Linux 核心參數(Kernel Parameter)

或者可以在核心參數後加上： selinux=0 （停止） 或 selinux=1 (開啟）參數

在 RHEL5 測 selinux=0 成功停止

在 RHEL5 測 selinux=1 開啟失敗（依然聽從 /etc/selinux/config 內 disabled 設定）

檔案 /boot/grub/menu.lst

title Fedora Core (2.6.18-1.2798.fc6)
       root (hd0,0)
       kernel /vmlinuz-2.6.18-1.2798.fc6 ro root=LABEL=/ rhgb quiet  selinux=0
       initrd /initrd-2.6.18-1.2798.fc6.img

[编辑]

檢查 SELinux 現時況態

要知到您現在是否使用 SELinux:

# getenforce
Enforcing

how to know the linux 32bit or 64 bit

arch
or
uname -a

how to configure option60 in dhcp server.

vi the dhcpd.conf

ddns-update-style none; #interim;
ignore client-updates;

# --- Vendor Option setting
option space VendorInfo;
# option VendorInfo.ZDlist code 3 = text; #for ZD
# option VendorInfo.FMlist code 1 = text; #for FlexMaster
option VendorInfo.address code 1 = ip-address;

subnet 192.168.61.0 netmask 255.255.255.0 {
option routers 192.168.61.10;
option subnet-mask 255.255.255.0;
option nis-domain "domain.org";
option domain-name "lab01.tdc.com";
option domain-name-servers 192.168.61.10;

class "Tikona" {
match if option vendor-class-identifier = "RUCKUS-CPE-2211";
vendor-option-space VendorInfo;
}

pool {
range 192.168.61.200 192.168.61.220;
max-lease-time 600;
allow members of "Tikona";
}

option time-offset -600; # Eastern Standard Time
# option ntp-servers 192.168.61.1;
# option netbios-name-servers 192.168.61.1;
# option netbios-node-type 2;
range dynamic-bootp 192.168.61.101 192.168.61.149;
default-lease-time 600;
max-lease-time 600;
# Vendor-option-space VendorInfo;
## option VendorInfo.ZDlist "192.168.61.40" ; #for zd
# option VendorInfo.FMlist "https://192.168.61.20/intune/server" ; #for FM

host ns {
hardware ethernet 00:1C:23:1C:57:2B;
fixed-address 192.168.61.40;} #DELL-D630

}

How to generating Client/Server certificates with a local CA

Creating the necessary directories

First of all we will create a directory tree where all certificate stuff will be kept. Fedora’s default directory is /etc/pki/tls/. So, as root, we create our own directories:

# mkdir -m 0755 /etc/pki_jungle

And then we create our CA’s directory tree:

# mkdir -m 0755 \
    /etc/pki_jungle/myCA \
    /etc/pki_jungle/myCA/private \
    /etc/pki_jungle/myCA/certs \
    /etc/pki_jungle/myCA/newcerts \
    /etc/pki_jungle/myCA/crl

• myCA is our Certificate Authority’s directory.
• myCA/certs directory is where our server certificates will be placed.
• myCA/newcerts directory is where openssl puts the created certificates in PEM (unencrypted) format and in the form cert_serial_number.pem (eg 07.pem). Openssl needs this directory, so we create it.
• myCA/crl is where our certificate revokation list is placed.
• myCA/private is the directory where our private keys are placed. Be sure that you set restrictive permissions to all your private keys so that they can be read only by root, or the user with whose priviledges a server runs. If anyone steals your private keys, then things get really bad.

Initial openssl configuration

We are going to copy the default openssl configuration file (openssl.cnf) to our CA’s directory. In Fedora, this file exists in /etc/pki/tls. So, we copy it to our CA’s dir and name it openssl.my.cnf. As root:

# cp /etc/pki/tls/openssl.cnf /etc/pki_jungle/myCA/openssl.my.cnf

This file does not need to be world readable, so we change its attributes:

# chmod 0600 /etc/pki_jungle/myCA/openssl.my.cnf

We also need to create two other files. This file serves as a database for openssl:

# touch /etc/pki_jungle/myCA/index.txt

The following file contains the next certificate’s serial number. Since we have not created any certificates yet, we set it to "01":

# echo '01' > /etc/pki_jungle/myCA/serial

Things to remember:
Here is a small legend with file extensions we will use for the created files and their meaning. All files that will be created will have one of these extensions:

• KEY - Private key (Restrictive permissions should be set on this)
• CSR - Certificate Request (This will be signed by our CA in order to create the server certificates. Afterwards it is not needed and can be deleted)
• CRT - Certificate (This can be publicly distributed)
• PEM - We will use this extension for files that contain both the Key and the server Certificate (Some servers need this). Permissions should be restrictive on these files.
• CRL - Certificate Revokation List (This can be publicly distributed)

Create the CA Certificate and Key

Now, that all initial configuration is done, we may create a self-signed certificate, that will be used as our CA’s certificate. In other words, we will use this to sign other certificate requests.

Change to our CA’s directory. This is where we should issue all the openssl commands because here is our openssl’s configuration file (openssl.my.cnf). As root:

# cd /etc/pki_jungle/myCA/

And then create your CA’s Certificate and Private Key. As root:

# openssl req -config openssl.my.cnf -new -x509 -extensions v3_ca -keyout private/myca.key -out certs/myca.crt -days 1825

This creates a self-signed certificate with the default CA extensions which is valid for 5 years. You will be prompted for a passphrase for your CA’s private key. Be sure that you set a strong passphrase. Then you will need to provide some info about your CA. Fill in whatever you like. Here is an example:

Country Name (2 letter code) [GB]:GR
State or Province Name (full name) [Berkshire]:Greece
Locality Name (eg, city) [Newbury]:Thessaloniki
Organization Name (eg, company) [My Company Ltd]:My Network
Organizational Unit Name (eg, section) []:My Certificate Authority
Common Name (eg, your name or your server's hostname) []:server.example.com
Email Address []:whatever@server.example.com

Two files are created:

• certs/myca.crt - This is your CA’s certificate and can be publicly available and of course world readable.
• private/myca.key - This is your CA’s private key. Although it is protected with a passphrase you should restrict access to it, so that only root can read it:

  # chmod 0400 /etc/pki_jungle/myCA/private/myca.key

More openssl configuration (mandatory)

Because we use a custom directory for our certificates’ management, some modifications to /etc/pki_jungle/myCA/openssl.my.cnf are necessary. Open it in your favourite text editor as root and find the following part (around line 35):

[ CA_default ]

dir     = ../../CA      # Where everything is kept
certs       = $dir/certs        # Where the issued certs are kept
crl_dir     = $dir/crl      # Where the issued crl are kept
database    = $dir/index.txt    # database index file.
#unique_subject = no            # Set to 'no' to allow creation of
                # several ctificates with same subject.
new_certs_dir   = $dir/newcerts     # default place for new certs.

certificate = $dir/cacert.pem   # The CA certificate
serial      = $dir/serial       # The current serial number
#crlnumber  = $dir/crlnumber    # the current crl number must be
                # commented out to leave a V1 CRL
crl     = $dir/crl.pem      # The current CRL
private_key = $dir/private/cakey.pem    # The private key
RANDFILE    = $dir/private/.rand    # private random number file

x509_extensions = usr_cert      # The extentions to add to the cert

You should modify the following settings in order to coform to our custom directory and our custom CA key and certificate:

[ CA_default ]

dir     = .                # <--CHANGE THIS
certs       = $dir/certs
crl_dir     = $dir/crl
database    = $dir/index.txt
#unique_subject = no

new_certs_dir   = $dir/newcerts

certificate = $dir/certs/myca.crt   # <--CHANGE THIS
serial      = $dir/serial
#crlnumber  = $dir/crlnumber

crl     = $dir/crl.pem
private_key = $dir/private/myca.key    # <--CHANGE THIS
RANDFILE    = $dir/private/.rand

x509_extensions = usr_cert

Create a Server certificate

Further openssl.my.cnf file’s customization is possible, so that we define our policy for certificate creation and signing or define our desired extensions for the new certificates. I may add this info to a future version of this document. It’s easy though, just try to familiarize yourself with the openssl.cnf’s structure and you’ll figure it out.

Anyway, the certificates we are going to create, without customizing openssl.my.cnf any further, are general purpose certificates and their usage in not restricted to server authentication only. One thing that you should take a note of is that the private keys will not be protected by a passphrase, so that when the services are restarted they do not ask for a passphrase. This means that you should set restrictive permissions on the private keys, so that only root or the user under whose priviledges a server runs can read these files.

Generate a Certificate Request

First, we change to our CA’s directory:

# cd /etc/pki_jungle/myCA/

Then we create the certificate request:

# openssl req -config openssl.my.cnf -new -nodes -keyout private/server.key -out server.csr -days 365

The -nodes option is needed so that the private key is not protected with a passphrase. If you do not intend to use the certificate for server authentication, you should not include it in the above command.
You can customize the number of days you want this certificate to be valid for.

You will be prompted for the certificate’s info. Here is an example:

Country Name (2 letter code) [GB]:GR
State or Province Name (full name) [Berkshire]:Greece
Locality Name (eg, city) [Newbury]:Thessaloniki
Organization Name (eg, company) [My Company Ltd]:My Network
Organizational Unit Name (eg, section) []:My Web Server
Common Name (eg, your name or your server's hostname) []:www.server.example.com
Email Address []:whatever@server.example.com

The Common Name (CN) is the info that uniquely distinguishes your service, so be sure that you type it correctly.
When prompted for some extra attributes (challenge password, optional company name) just hit the [Enter] key.

Two files are created:

• server.csr - this is the certificate request.
• private/server.key - this is the private key, which is not protected with a passphrase.

Set restrictive permissions on the private key. Only root or the user that is used to run the server should be able to read it. For example:

# chown root.root /etc/pki_jungle/myCA/private/server.key
# chmod 0400 /etc/pki_jungle/myCA/private/server.key

Or:

# chown root.apache /etc/pki_jungle/myCA/private/server.key
# chmod 0440 /etc/pki_jungle/myCA/private/server.key

Sign the Certificate Request

Now we are going to sign the certificate request and generate the server’s certificate.
First, we change to our CA’s directory:

# cd /etc/pki_jungle/myCA/

Then we sign the certificate request:

# openssl ca -config openssl.my.cnf -policy policy_anything -out certs/server.crt -infiles server.csr

You will need to supply the CA’s private key in order to sign the request. You can check the openssl.my.cnf file about what policy_anything means. In short, the fields about the Country, State or City is not required to match those of your CA’s certificate.

After all this is done two new files are created:

• certs/server.crt - this is the server’s certificate, which can be made available publicly.
• newcerts/01.pem - This is exactly the same certificate, but with the certificate’s serial number as a filename. It is not needed.

You can now delete the certificate request (server.csr). It’s no longer needed:

# rm -f /etc/pki_jungle/myCA/server.csr

Verify the certificate

You can see the certificate’s info with the following:

# openssl x509 -subject -issuer -enddate -noout -in /etc/pki_jungle/myCA/certs/server.crt

Or the following:

# openssl x509 -in certs/server.crt -noout -text

And verify that the certificate is valid for server authentication with the following:

# openssl verify -purpose sslserver -CAfile /etc/pki_jungle/myCA/certs/myca.crt /etc/pki_jungle/myCA/certs/server.crt

Server certificate and key in one file

Some servers, for example vsftpd, require that both the private key and the certificate exist in the same file. In a situation like that just do the following:

# cat certs/server.crt private/server.key > private/server-key-cert.pem

You should restrict access to the final file and delete server.crt and server.key since thay are no longer needed.

# chown root.root private/server-key-cert.pem
# chmod 0400 private/server-key-cert.pem
# rm -f certs/server.crt
# rm -f private/server.key

Revoke a Server Certificate

If you do not want a certificate to be valid any more, you have to revoke it. This is done with the command:

# openssl ca -config openssl.my.cnf -revoke certs/server.crt

Then you should generate a new CRL (Certificate Revokation List):

# openssl ca -config openssl.my.cnf -gencrl -out crl/myca.crl

The CRL file is crl/myca.crl.

Distribute your certificates and CRL

Your CA’s certificate and your servers’ certificates should be distributed to those who trust you so they can import them in their client software (web browsers, ftp clients, email clients etc). The CRL should also be published.

Generate client certificate/key pair

1. Either choose to encrypt the key(a) or not(b)
   a. openssl genrsa -des3 -out client.key 1024 (Encrypt the client key with a passphrase )
   b. openssl genrsa -out client.key 1024 (Don't encrypt the client key) 2) openssl req -key client.key -new -out client.req
2. openssl x509 -req -in client.req -CA CA.pem -CAkey privkey.pem -CAserial file.srl -out Client.pem

-contents of "file.srl" is a two digit number. eg. "00"

Convert PEM Format Certificate TO PKCS12 Format Certificate

Most browsers, including Internet Explorer, require that client certificates (which includes proxy certificates) be in the PKCS12 format rather than the X509 PEM format. Additionally, Java KeyStores require certificates to be in PKCS12 format. To convert a PEM formatted certificate to PKCS12 format, you need both the certificate and the private key for that certificate. Here's a typical openssl command and the resulting interactive session when converting PEM format to PKCS12 format:

> openssl pkcs12 -export -in cert.pem -inkey key.pem -out cred.p12
Enter Export Password:whatever
Verifying - Enter Export Password:whatever
>

First, an explanation of the command line options:

• -export - generate a PKCS12 formatted file.
• -in cert.pem - read in the X509 PEM formatted certificate from the file cert.pem.
• -inkey key.pem - read in the X509 PEM formatted key from the file key.pem.
• -out cred.p12 - write out the PKCS12 formatted 'credential' to the file cred.p12.

Generating Client/Server Certificates wtih a local CA

Generating Client/Server certificates with a local CA
*make sure openssl points to the correct instillation (%which openssl). Mine is aliased to /usr/local/openssl/bin/openssl

Generate a CA
1) openssl req -out ca.pem -new -x509
-generates CA file "ca.pem" and CA key "privkey.pem"

Generate server certificate/key pair
- no password required.
2) openssl genrsa -out server.key 1024
3) openssl req -key server.key -new -out server.req
4) openssl x509 -req -in server.req -CA CA.pem -CAkey privkey.pem -CAserial file.srl -out server.pem
-contents of "file.srl" is a two digit number. eg. "00"

Generate client certificate/key pair

5) Either choose to encrypt the key(a) or not(b)
a. Encrypt the client key with a passphrase
openssl genrsa -des3 -out client.key 1024
b. Don't encrypt the client key
openssl genrsa -out client.key 1024
6) openssl req -key client.key -new -out client.req
7) openssl x509 -req -in client.req -CA CA.pem -CAkey privkey.pem -CAserial file.srl -out client.pem
-contents of "file.srl" is a two digit number. eg. "00"

8) DONE

The Link:

http://acs.lbl.gov/~boverhof/openssl_certs.html

http://security.ncsa.uiuc.edu/research/grid-howtos/usefulopenssl.php

config vlan in FC8

• 1. Network configuration on the Linux server:
  a) The main interface ethX (the Ethernet interface connects to the test-bed): 192.168.0.252/24
  b) Creating the sub-interfaces:
  - Make a copy of /etc/sysconfig/network-scripts/ifcfg-ethX and name it ifcfg- ethX:1.
  - Open the file created in the step above and change the device name, IP address and subnet mask appropriately (ifcfg-ethX:1, 172.21.0.252/16).
  - Repeat the two steps above to make another 5 sub-interfaces with IP addresses ranging from 172.22.0.252 to 172.26.0.252.
  - Restart network service to bring the new sub-interfaces up.
  c) Creating VLAN interfaces:
  - Use the command ‘vconfig add eth0 2’ to add vlan 2 to the server.
  - Use the command ‘vconfig add eth0 4094’ to add vlan 4094 to the server.
  - Use the command ‘ifconfig eth0.2 20.0.2.252 netmask 255.255.255.0’ to configure IP d)configuration for interface eth0.2.
  - Use the command ‘ifconfig eth0.4094 20.15.254.252 netmask 255.255.255.0’ to configure IP configuration for interface eth0.4094.
  - Go to /etc/sysconfig/network-scripts/
  - Make clone of the configuration file of the ethernet interface that connects to the testbed (it is ifcfg-eth0 in my system) and name them ifcfg-eth0.2 and ifcfg-eth0.4094.
  - Edit those files to update the device name to the new names (eth0.2, eth0.4094), add VLAN=yes, update IPADDR to the new addresses (20.0.2.252/24, 20.15.254.252/24)
  - Restart network service

• 2. Install and configure DHCP Server:
  - The Dynamic Host Configuration Protocol (DHCP) can be used to assign IP addresses to a network’s machines DHCP supports the static assignment of IP addresses, using a preconfigured table of associations from physical (MAC) addresses to IP addresses. DHCP also supports dynamic IP assignment, with respect to an IP address range specified during DHCP setup. In our testbed, the DHCP Server is used for assigning IP addresses to the ZoneDirector and the associated clients.
  - DHCP can be installed on the Kickstart server the Fedora Core’s yum package. Use yum to add DHCP to a minimal installation of Fedora Core 4 with the following command.
  yum install DHCP
  After installing DHCP Server on the server, change some value in the dhcpd.conf file as below:
  
  

ddns-update-style interim;
ignore client-updates;
option domain-name-servers 192.168.0.252;
subnet 192.168.0.0 netmask 255.255.255.0 {

# --- default gateway
option routers 192.168.0.252;
option subnet-mask 255.255.255.0;
option domain-name "mydomain.com";
# --- Selects point-to-point node (default is hybrid). Don't change this unless
# -- you understand Netbios very well
# option netbios-node-type 2;
range dynamic-bootp 192.168.0.128 192.168.0.250;

default-lease-time 21600;
max-lease-time 43200;

# we want the nameserver to appear at a fixed address

host ZoneDirector {

hardware ethernet 00:1D:2E:00:45:60; #MAC address of ZoneDirector
fixed-address 192.168.0.2;

}

}

# For vlan 2
subnet 20.0.2.0 netmask 255.255.255.0 {
# --- default gateway
option routers 20.0.2.252;
option domain-name-servers 20.0.2.252;
range dynamic-bootp 20.0.2.100 20.0.2.200;

default-lease-time 21600;
max-lease-time 43200;

}

# For vlan 4094
subnet 20.15.254.0 netmask 255.255.255.0 {
# --- default gateway
option routers 20.15.254.252;
option domain-name-servers 20.15.254.252;
range dynamic-bootp 20.15.254.100 20.15.254.200;

default-lease-time 21600;
max-lease-time 43200;
}