Templated Functions

C++ templates can be used both for classes and for functions in C++. Templated functions are actually a bit easier to use than templated classes, as the compiler can often deduce the desired type from the function's argument list.

The syntax for declaring a templated function is similar to that for a templated class:

template <class type> type func_name(type arg1, ...);

For instance, to declare a templated function to add two values together, you could use the following syntax:

template <class type> type add(type a, type b)
{
    return a + b;
}

Now, when you actually use the add function, you can simply treat it like any other function because the desired type is also the type given for the arguments. This means that upon compiling the code, the compiler will know what type is desired:

int x = add(1, 2);

will correctly deduce that "type" should be int. This would be the equivalent of saying:

int x = add<int>(1, 2);

where the template is explicitly instantiated by giving the type as a template parameter.

On the other hand, type inference of this sort isn't always possible because it's not always feasible to guess the desired types from the arguments to the function. For instance, if you wanted a function that performed some kind of cast on the arguments, you might have a template with multiple parameters:

template <class type1, class type2> type2 cast(type1 x)
{
    return (type2)x;
}

Using this function without specifying the correct type for type2 would be impossible. On the other hand, it is possible to take advantage of some type inference if the template parameters are correctly ordered. In particular, if the first argument must be specified and the second deduced, it is only necessary to specify the first, and the second parameter can be deduced.

For instance, given the following declaration

template <class rettype, class argtype> rettype cast(argtype x)
{
    return (rettype)x;
}

this function call specifies everything that is necessary to allow the compiler deduce the correct type:

cast<double>(10);

which will cast an int to a double. Note that arguments to be deduced must always follow arguments to be specified. (This is similar to the way that default arguments to functions work.)

You might wonder why you cannot use type inference for classes in C++. The problem is that it would be a much more complex process with classes, especially as constructors may have multiple versions that take different numbers of parameters, and not all of the necessary template parameters may be used in any given constructor.

Templated Classes with Templated Functions

It is also possible to have a templated class that has a member function that is itself a template, separate from the class template. For instance,

template <class type> class TClass
{
    // constructors, etc
    
    template <class type2> type2 myFunc(type2 arg);
};

The function myFunc is a templated function inside of a templated class, and when you actually define the function, you must respect this by using the template keyword twice:

template <class type>  // For the class
    template <class type2>  // For the function
    type2 TClass<type>::myFunc(type2 arg)
    {
        // code
    }

The following attempt to combine the two is wrong and will not work:

// bad code!
template <class type, class type2> type2 TClass<type>::myFunc(type2 arg)
{
    // ...
}

because it suggests that the template is entirely the class template and not a function template at all.


Source

   

Templates and Templated Classes in C++

What's better than having several classes that do the same thing to different datatypes? One class that lets you choose which datatype it acts on.
Templates are a way of making your classes more abstract by letting you define the behavior of the class without actually knowing what datatype will be handled by the operations of the class. In essence, this is what is known as generic programming; this term is a useful way to think about templates because it helps remind the programmer that a templated class does not depend on the datatype (or types) it deals with. To a large degree, a templated class is more focused on the algorithmic thought rather than the specific nuances of a single datatype. Templates can be used in conjunction with abstract datatypes in order to allow them to handle any type of data. For example, you could make a templated stack class that can handle a stack of any datatype, rather than having to create a stack class for every different datatype for which you want the stack to function. The ability to have a single class that can handle several different datatypes means the code is easier to maintain, and it makes classes more reusable.
The basic syntax for declaring a templated class is as follows:

template <class a_type> class a_class {...};

The keyword 'class' above simply means that the identifier a_type will stand for a datatype. NB: a_type is not a keyword; it is an identifier that during the execution of the program will represent a single datatype. For example, you could, when defining variables in the class, use the following line:

a_type a_var;

and when the programmer defines which datatype 'a_type' is to be when the program instantiates a particular instance of a_class, a_var will be of that type.
When defining a function as a member of a templated class, it is necessary to define it as a templated function:

template<class a_type> void a_class<a_type>::a_function(){...}
               

When declaring an instance of a templated class, the syntax is as follows:

a_class<int> an_example_class;
              

An instantiated object of a templated class is called a specialization; the term specialization is useful to remember because it reminds us that the original class is a generic class, whereas a specific instantiation of a class is specialized for a single datatype (although it is possible to template multiple types).
Usually when writing code it is easiest to precede from concrete to abstract; therefore, it is easier to write a class for a specific datatype and then proceed to a templated - generic - class. For that brevity is the soul of wit, this example will be brief and therefore of little practical application.
We will define the first class to act only on integers.

class calc
{
  public:
    int multiply(int x, int y);
    int add(int x, int y);
 };
int calc::multiply(int x, int y)
{
  return x*y;
}
int calc::add(int x, int y)
{
  return x+y;
}

We now have a perfectly harmless little class that functions perfectly well for integers; but what if we decided we wanted a generic class that would work equally well for floating point numbers? We would use a template.

template <class A_Type> class calc
{
  public:
    A_Type multiply(A_Type x, A_Type y);
    A_Type add(A_Type x, A_Type y);
};
template <class A_Type> A_Type calc<A_Type>::multiply(A_Type x,A_Type y)
{
  return x*y;
}
template <class A_Type> A_Type calc<A_Type>::add(A_Type x, A_Type y)
{
  return x+y;
}

To understand the templated class, just think about replacing the identifier A_Type everywhere it appears, except as part of the template or class definition, with the keyword int. It would be the same as the above class; now when you instantiate an
object of class calc you can choose which datatype the class will handle.

calc <double> a_calc_class;

Templates are handy for making your programs more generic and allowing your code to be reused later.

Source

The C Preprocessor

The C preprocessor modifies a source code file before handing it over to the compiler. You're most likely used to using the preprocessor to include files directly into other files, or #define constants, but the preprocessor can also be used to create "inlined" code using macros expanded at compile time and to prevent code from being compiled twice.

There are essentially three uses of the preprocessor--directives, constants, and macros. Directives are commands that tell the preprocessor to skip part of a file, include another file, or define a constant or macro. Directives always begin with a sharp sign (#) and for readability should be placed flush to the left of the page. All other uses of the preprocessor involve processing #define'd constants or macros. Typically, constants and macros are written in ALL CAPS to indicate they are special (as we will see).

Header Files

The #include directive tells the preprocessor to grab the text of a file and place it directly into the current file. Typically, such statements are placed at the top of a program--hence the name "header file" for files thus included.

Constants

If we write

#define [identifier name] [value]

whenever [identifier name] shows up in the file, it will be replaced by [value].

If you are defining a constant in terms of a mathematical expression, it is wise to surround the entire value in parentheses:

#define PI_PLUS_ONE (3.14 + 1)

By doing so, you avoid the possibility that an order of operations issue will destroy the meaning of your constant:

x = PI_PLUS_ONE * 5;

Without parentheses, the above would be converted to

x = 3.14 + 1 * 5;

which would result in 1 * 5 being evaluated before the addition, not after. Oops!

It is also possible to write simply

#define [identifier name]

which defines [identifier name] without giving it a value. This can be useful in conjunction with another set of directives that allow conditional compilation.

Conditional Compilation

There are a whole set of options that can be used to determine whether the preprocessor will remove lines of code before handing the file to the compiler. They include #if, #elif, #else, #ifdef, and #ifndef. An #if or #if/#elif/#else block or a #ifdef or #ifndef block must be terminated with a closing #endif.

The #if directive takes a numerical argument that evaluates to true if it's non-zero. If its argument is false, then code until the closing #else, #elif, of #endif will be excluded.

Commenting out Code

Conditional compilation is a particularly useful way to comment out a block of code that contains multi-line comments (which cannot be nested).

#if 0
/* comment ...
*/

// code

/* comment */
#endif

Avoiding Including Files Multiple Times (idempotency)

Another common problem is that a header file is required in multiple other header files that are later included into a source code file, with the result often being that variables, structs, classes or functions appear to be defined multiple times (once for each time the header file is included). This can result in a lot of compile-time headaches. Fortunately, the preprocessor provides an easy technique for ensuring that any given file is included once and only once.

By using the #ifndef directive, you can include a block of text only if a particular expression is undefined; then, within the header file, you can define the expression. This ensures that the code in the #ifndef is included only the first time the file is loaded.

#ifndef _FILE_NAME_H_
#define _FILE_NAME_H_

/* code */

#endif // #ifndef _FILE_NAME_H_

Notice that it's not necessary to actually give a value to the expression _FILE_NAME_H_. It's sufficient to include the line "#define _FILE_NAME_H_" to make it "defined". (Note that there is an n in #ifndef--it stands for "if not defined").

A similar tactic can be used for defining specific constants, such as NULL:

#ifndef NULL
#define NULL (void *)0
#endif // #ifndef NULL

Notice that it's useful to comment which conditional statement a particular #endif terminates. This is particularly true because preprocessor directives are rarely indented, so it can be hard to follow the flow of execution.

Macros

The other major use of the preprocessor is to define macros. The advantage of a macro is that it can be type-neutral (this can also be a disadvantage, of course), and it's inlined directly into the code, so there isn't any function call overhead. (Note that in C++, it's possible to get around both of these issues with templated functions and the inline keyword.)

A macro definition is usually of the following form:

#define MACRO_NAME(arg1, arg2, ...) [code to expand to]

For instance, a simple increment macro might look like this:

#define INCREMENT(x) x++

They look a lot like function calls, but they're not so simple. There are actually a couple of tricky points when it comes to working with macros. First, remember that the exact text of the macro argument is "pasted in" to the macro. For instance, if you wrote something like this:

#define MULT(x, y) x * y

and then wrote

int z = MULT(3 + 2, 4 + 2);

what value do you expect z to end up with? The obvious answer, 30, is wrong! That's because what happens when the macro MULT expands is that it looks like this:

int z = 3 + 2 * 4 + 2;    // 2 * 4 will be evaluated first!

So z would end up with the value 13! This is almost certainly not what you want to happen. The way to avoid it is to force the arguments themselves to be evaluated before the rest of the macro body. You can do this by surrounding them by parentheses in the macro definition:

#define MULT(x, y) (x) * (y)
// now MULT(3 + 2, 4 + 2) will expand to (3 + 2) * (4 + 2)

But this isn't the only gotcha! It is also generally a good idea to surround the macro's code in parentheses if you expect it to return a value. Otherwise, you can get similar problems as when you define a constant. For instance, the following macro, which adds 5 to a given argument, has problems when embedded within a larger statement:

#define ADD_FIVE(a) (a) + 5

int x = ADD_FIVE(3) * 3;
// this expands to (3) + 5 * 3, so 5 * 3 is evaluated first
// Now x is 18, not 24!

To fix this, you generally want to surround the whole macro body with parentheses to prevent the surrounding context from affecting the macro body.

#define ADD_FIVE(a) ((a) + 5)

int x = ADD_FIVE(3) * 3;

On the other hand, if you have a multiline macro that you are using for its side effects, rather than to compute a value, you probably want to wrap it within curly braces so you don't have problems when using it following an if statement.

// We use a trick involving exclusive-or to swap two variables
#define SWAP(a, b)  a ^= b; b ^= a; a ^= b; 

int x = 10;
int y = 5;

// works OK
SWAP(x, y);

// What happens now?
if(x < 0)
    SWAP(x, y);

When SWAP is expanded in the second example, only the first statement, a ^= b, is governed by the conditional; the other two statements will always execute. What we really meant was that all of the statements should be grouped together, which we can enforce using curly braces:

#define SWAP(a, b)  {a ^= b; b ^= a; a ^= b;} 

Now, there is still a bit more to our story! What if you write code like so:

#define SWAP(a, b)  { a ^= b; b ^= a; a ^= b; }

int x = 10;
int y = 5;
int z = 4;

// What happens now?
if(x < 0)
    SWAP(x, y);
else
    SWAP(x, z); 

Then it will not compile because semicolon after the closing curly brace will break the flow between if and else. The solution? Use a do-while loop:

#define SWAP(a, b)  do { a ^= b; b ^= a; a ^= b; } while ( 0 )

int x = 10;
int y = 5;
int z = 4;

// What happens now?
if(x < 0)
    SWAP(x, y);
else
    SWAP(x, z); 

Now the semi-colon doesn't break anything because it is part of the expression. (By the way, note that we didn't surround the arguments in parentheses because we don't expect anyone to pass an expression into swap!)

More Gotchas

By now, you've probably realized why people don't really like using macros. They're dangerous, they're picky, and they're just not that safe. Perhaps the most irritating problem with macros is that you don't want to pass arguments with "side effects" to macros. By side effects, I mean any expression that does something besides evaluate to a value. For instance, ++x evaluates to x+1, but it also increments x. This increment operation is a side effect.

The problem with side effects is that macros don't evaluate their arguments; they just paste them into the macro text when performing the substitution. So something like

#define MAX(a, b) ((a) < (b) ? (b) : (a))
int x = 5, y = 10;
int z = MAX(x++, y++);

will end up looking like this:

int x = (x++ < y++ ? y++ : x++)

The problem here is that y++ ends up being evaluated twice! The nasty consequence is that after this expression, y will have a value of 12 rather than the expected 11. This can be a real pain to debug!

Multiline macros

Until now, we've seen only short, one line macros (possibly taking advantage of the semicolon to put multiple statements on one line.) It turns out that by using a the "\" to indicate a line continuation, we can write our macros across multiple lines to make them a bit more readable.

For instance, we could rewrite swap as

#define SWAP(a, b)  {                   \
                        a ^= b;         \
                        b ^= a;         \ 
                        a ^= b;         \
                    } 

Notice that you do not need a slash at the end of the last line! The slash tells the preprocessor that the macro continues to the next line, not that the line is a continuation from a previous line.

Aside from readability, writing multi-line macros may make it more obvious that you need to use curly braces to surround the body because it's more clear that multiple effects are happening at once.

Advanced Macro Tricks

In addition to simple substitution, the preprocessor can also perform a bit of extra work on macro arguments, such as turning them into strings or pasting them together.

Pasting Tokens

Each argument passed to a macro is a token, and sometimes it might be expedient to paste arguments together to form a new token. This could come in handy if you have a complicated structure and you'd like to debug your program by printing out different fields. Instead of writing out the whole structure each time, you might use a macro to pass in the field of the structure to print.

To paste tokens in a macro, use ## between the two things to paste together.

For instance

#define BUILD_FIELD(field) my_struct.inner_struct.union_a.##field

Now, when used with a particular field name, it will expand to something like

my_struct.inner_struct.union_a.field1

The tokens are literally pasted together.

String-izing Tokens

Another potentially useful macro option is to turn a token into a string containing the literal text of the token. This might be useful for printing out the token. The syntax is simple--simply prefix the token with a pound sign (#).

#define PRINT_TOKEN(token) printf(#token " is %d", token)

For instance, PRINT_TOKEN(foo) would expand to

printf("<foo>" " is %d" <foo>)

(Note that in C, string literals next to each other are concatenated, so something like "token" " is " " this " will effectively become "token is this". This can be useful for formatting printf statements.)

For instance, you might use it to print the value of an expression as well as the expression itself (for debugging purposes).

PRINT_TOKEN(x + y);

Avoiding Macros in C++

In C++, you should generally avoid macros when possible. You won't be able to avoid them entirely if you need the ability to paste tokens together, but with templated classes and type inference for templated functions, you shouldn't need to use macros to create type-neutral code. Inline functions should also get rid of the need for macros for efficiency reasons. (Though you aren't guaranteed that the compiler will inline your code.)

Moreover, you should use const to declare typed constants rather than #define to create untyped (and therefore less safe) constants. Const should work in pretty much all contexts where you would want to use a #define, including declaring static sized arrays or as template parameters.


Source


   

Using Firewall Builder To Configure Router Access Lists - PT 3

Getting Started: Configuring Cisco Router ACL

For the following sections we are going to assume that the following rules have been defined for the router configuration shown above.

Step 4: Compile and Install

In Firewall Builder the process of converting the rules from the Firewall Builder GUI syntax to the target device commands is called compiling the configuration.
To compile, click on the Compile icon which looks like a hammer . If you haven't saved your configuration file yet you will be asked to do so. After you save your file a wizard will be displayed that lets you select which firewall(s) you want to compile. In this example we are going to complie the firewall called la-rtr-1 configured with the rules above.
If there aren't any errors, you should see some messages scroll by in the main window and a message at the top left stating Success.
To view the output of the compile, click on the button that says Inspect Generated Files. This will open the file that contains the commands in Cisco command format. Note that any line that starts with "!" is a comment.

The output from the compiler is automatically saved in a file in the same directory as the data file that was used to create it. The generated files are named with the firewall name and a .fw extension. In our example the generated configuration file is called la-rtr-1.fw. You can copy and copy and paste the commands from this file to your router or you can use the built-in Firewall Builder installer.

 

Installing

Firewall Builder can install the generated configuration file for you using SSH. To use the installer we need to identify one of the router interfaces as the "Management Interface". This tells Firewall Builder which IP address to connect to on the router.
Do this by double-clicking the firewall object to expand it, and then double-clicking on the interface name that you want to assign as the management interface. In our case this is interface FastEthernet0/1 which is the interface connected to the internal network.

CAUTION! Any time you are changing access lists on your router you face the risk of locking yourself out of the device. Please be careful to always inspect your access lists closely and make sure that you will be able to access the router after the access list is installed.
To install your access lists on the router, click on the install icon . This will bring up a wizard where you will select the firewall to install. Click Next > to install the selected firewall.

Firewall Builder will compile your rules converting them in to Cisco access list command line format. After the compile completes successfully click Next >. Enter your username, password and enable password.

After the access list configuration is installed you see a message at the bottom of the main window and the status indicator in the upper left corner of the wizard will indicate if the installation was successful.

By default Firewall Builder will connect to your router using SSH and send the commands line-by-line to the router. Depending on the size of your access lists this can be slow.
If your router is running IOS version 12.4 you can select an option to have Firewall Builder scp the generated configuration file to the router instead of applying it line-by-line. This is much faster and is recommended if your router supports it.
This requires ssh version 2 to be enabled on the router and scp server to be enabled. You can find complete instructions for enabling SCP installation in the Firewall Builder Users Guide.




Source

Using Firewall Builder To Configure Router Access Lists - PT 2

Getting Started: Configuring Cisco Router ACL

Reminder - In this tutorial we are configuring access lists on a router that has the following interface configuration.

Our goal is to implement the following four rules as access control lists on the router.

• Allow inside traffic (10.0.0.0/24) through the router to any Internet address for the HTTP and HTTPS protocols
• Allow inside traffic (10.0.0.0/24) through the router to a specific IP address (198.51.100.1) for the POP3 protocol.
• Allow inside traffic (10.0.0.0/24) to the router's inside interface (FastEthernet0/1) for the SSH protocol.
• Block all incoming traffic to the router's outside interface (FastEthernet0/0).

Step 3: Configure Access Lists

After we created the firewall object la-rtr-1 it was automatically opened in the object tree and its Policy object was opened in the main window for editing. The Policy object is where access list rules are configured.
To add a new rule to the Policy, click on the green icon at the top left of the main window. This creates a new rule with default values set to deny all.

In Firewall Builder everything is based on the concept of objects. To configure rules that will be converted in to access lists you simply find the object you want in the tree and drag-and-drop it to the correct section of the rule.
The first rule in our example is to allow internal network traffic to use the HTTP and HTTPS protocols to access the Internet. In configuration the router is NAT'ing the internal network to the IP address on the FastEthernet interface. Since the order of operations on Cisco routers is that NAT takes place before the outbound access list is checked the Source for the outbound rules must be the post-NAT IP address which is represented by the IP interface object under the outside FastEthernet0/0 interface.

After you drop the interface IP object into the rule the Source section will change from Any to la-rtr-1:FastEthernet0/0:ip.

Since we want this rule to allow traffic to the Internet we will leave the Destination object set to Any. The Any object in Firewall Builder is the same as the "any" parameter in Cisco CLI commands for access lists.
Next we want to define the protocols or services this rule will allow. The example calls for the HTTP and HTTPS services to be allowed out to the Internet.
Firewall Builder comes with hundreds of predefined objects including almost all standard protocols. To access these objects switch to the Standard library by selecting it from the drop down at the top of the Object tree window.



After you have switched to the Standard library you can navigate to the HTTP service by opening the Services folder, then opening the TCP folder and scrolling down until you find the http object.
Once you find the http object, drag-and-drop from the tree on the left in to the Service section of the rule in the Rules window.

Repeat this process to add the HTTPS service to the rule. Drag-and-drop the https object from the tree on the left to the Service section of the rule in the Rules window.
NOTE: Notice that you can have more than one service in a single rule. Firewall Builder will automatically expand this rule in to multiple rules in the Cisco command syntax.
IMPORTANT! To access the objects you previously created, including the router, you need to switch back to the User library. Do this by going to the drop down menu at the top of the object tree panel and switch the selected library from Standard to User.
Due to the NAT configuration that is setup on the router traffic from the 10.0.0.0/24 network will be NAT'ed by the router to its outside IP address (192.0.2.1). This means the traffic that we want to match with our rule will be sent out the FastEthernet0/0 interface. Set the interface in the rule by dragging-and-dropping the FastEthernet0/0 interface object from the tree to the Interface section of the rule.

Traffic will be going in the outbound direction on this interface, so we right-click in the Direction section and select Outbound. We want this traffic to be allowed, so we need to change the Action associated with this rule from Deny to Accept. Do this by right-clicking on the Action section of the rule an selecting Accept. Finally, since this is a rule that we expect to match a lot of traffic disable logging by right-clicking in the Options section and selecting Logging Off. You should now see a rule that looks like:

The next rule in our example allows the internal network to access an external POP3 server. Click on the rule you just created and then right-click in the rule number section and select "Add New Rule Below".

To access the objects that we created earlier we need to switch back to the User library. Click on the drop down menu that says Standard and select User from the list. Drag-and-drop the IP address object for the router's outside inteface from the tree on the left to the rule you just created placing it in the Source section.
NOTE: You can also copy-and-paste objects. For example, you can right-click on the la-rtr-01:FastEthernet0/0:ip object in the first rule and select Copy. Navigate to the Source section of the new rule you just created and right-click and select Paste.
This rule requires both the Source and Destination to be set, so go to the Addresses folder and drag-and-drop the POP3 Server object to the Destination section of the rule.
The POP3 protocol object is located in the Standard library, so select it from the dropdown menu at the top of the Object Window. To find the POP3 object you can scroll down through the object tree, or you can simply type pop3 in to the filter field. This will display all objects in the current library that contain pop3.

Drag-and-drop the filtered object from the tree to the Sevice section of the rule you are currently editing. Clear the filter field by clicking the X to the right of the input box and then switch back to the User library by selecting it in the dropdown menu at the top of the object panel.
To set the interface the rule should be applied to drag-and-drop the "outside" interface FastEthernet0/0 to the Interface section of the rule.
To change the Action to Accept right-click in the Action section of the rule and select Accept. To disable logging for this rule, right-click on the Options section and select Logging Off.
You should now have 2 rules that look like this:

Now we need to add our 3rd rule. This rule is designed to allow SSH traffic from the internal network to the router’s inside interface.
Create a new rule below the last rule by selecting the last rule and right-clicking and selecting Add New Rule Below from the menu. This will create a new rule configured with the default values to deny all.
Modify this rule by dragging-and-dropping the Internal Network object from the tree to the Source section of the newly created rule. To restrict the rule to only allow traffic destined to the IP address of the router's FastEthernet1/0 interface, double-click on the firewall object's FastEthernet1/0 interface to expand it. Drag-and- drop the IP address of the interface to the Destination section of the rule.
To set the service to SSH switch to the Standard library by selecting it from the dropdown menu above the object tree and then type in "ssh" in the filter box. Drag-and-drop the ssh object from the tree to the Service section. Clear the filter by clicking on the X next to the filter input text box.
Switch back to the User library by selecting it from the dropdown menu above the object tree. Double click the la-rtr-1 object to expand it and drag-and-drop the FastEthernet1/0 interface to the Interface section of the rule.
Since this rule only applies to inbound traffic on this interface set the direction to Inbound by right-clicking in the Direction section and selecting Inbound. Finally, change the action for the rule by right- clicking on the Action section and selecting Accept. Since this rule defines access to the router via SSH we will leave logging enabled for this rule.
You should now have 3 rules that look like:

Since we added a rule that will create an inbound access list on the inside FastEthernet0/1 interface, we need to add rules that allow the traffic for the first two rules inbound on inside interface. Otherwise this traffic would be blocked coming in to the router and it would never reach the outbound access list on the outside interface. Follow the same steps from above, but set the interface to the inside FastEthernet0/1 interface and set the Direction as Inbound.
Your rules should now look like this:

Finally, we need to add a rule to the router's outside interface that blocks all traffic trying to access the router directly on its outside interface IP address.
To do this we follow the same process from the earlier examples. Since this rule should match all traffic coming from the Internet we leave the Source section as Any. Set the Destination section by dragging-and-dropping the IP address object for outside interface FastEthernet0/0. We want to block all serices, so leave the Service section set to Any. We want this rule to match incoming traffic, so we right-click in the Direction section and select Inbound. The desired Action is to deny the traffic, so we leave that as the default. Finally since this rule will potentially match a lot of traffic we disable logging by right-clicking on the Options section and selecting Logging Off.
We are now done configuring the rules for our access lists and the configuration should look like:

In the next section we will go through the process of converting these rules in to Cisco commands and installing them on the router.




Source

Using Firewall Builder To Configure Router Access Lists - PT 1

Firewall Builder is a firewall configuration and management GUI that supports configuring a wide range of firewalls from a single application. Supported firewalls include Linux iptables, BSD pf, Cisco ASA/PIX, Cisco router access lists and many more. The complete list of supported platforms along with downloadable binary packages and soure code can be found at http://www.fwbuilder.org.
This tutorial is the first in a series of howtos that will walk through the basic steps of using Firewall Builder to configure each of the supported firewall platforms. In this tutorial we will configure Access Control Lists (ACL) on a Cisco router.
The diagram below shows a simple 2 interface router configuration with the router acting as a gateway to the Internet for a private LAN network.

We will use Firewall Builder to implement the following basic rules as access lists on the router.

• Allow inside traffic (10.0.0.0/24) through the router to any Internet address for the HTTP and HTTPS protocols
• Allow inside traffic (10.0.0.0/24) through the router to a specific IP address (198.51.100.1) for the POP3 protocol.
• Allow inside traffic (10.0.0.0/24) to the router's inside interface (FastEthernet0/1) for the SSH protocol.
• Block all incoming traffic to the rotuer's outside interface FastEthernet0/0.

Note that Cisco router access lists have an implicit deny all at the end of every access list, so anything that we do not setup a rule to explicitly permit will be denied.
The NAT configuration on the router is as follows:

interface FastEthernet0/0
ip nat outside

interface FastEthernet0/1
ip nat inside

access-list 1 permit 10.0.0.0 0.0.0.255

ip nat inside source list 1 interface FastEthernet0/0 overload

Step 1: Create Network Objects

We are going to start by creating the objects that will be used in the rules. Firewall Builder includes hundreds of predefined objects, including most standard protocols, so to implement the rules above we will only need to create the objects that are specific to our network. For our rules this means we need to create objects for the internal 10.0.0.0/24 network and for the POP3 server with an IP address of 198.51.100.1.

 

Source

Visual MySQL Database Design in MySQL Workbench

MySQL Workbench is a visual database design tool recently released by MySQL AB. The tool is specifically for designing MySQL database.
MySQL Workbench has many functions and features; this article by Djoni Darmawikarta shows some of them by way of an example. We’ll build a physical data model for an order system where an order can be a sale order or a purchase order, and then, forward-engineer our model into an MySQL database.
MySQL Workbench is a visual database design tool recently released by MySQL AB. The tool is specifically for designing MySQL database.
What you build in MySQL Workbench is called physical data model. A physical data model is a data model for a specific RDBMS product; the model in this article will have some MySQL unique specifications. We can generate (forward-engineer) the database objects from its physical model, which in addition to tables and their columns, can also include other objects such as view.
MySQL Workbench has many functions and features; this article by Djoni Darmawikarta shows some of them by way of an example. We’ll build a physical data model for an order system where an order can be a sale order or a purchase order; and then, forward-engineer our model into an MySQL database.
The physical model of our example in EER diagram will look like in the following MySQL Workbench screenshot.

Creating ORDER Schema

Let’s first create a schema where we want to store our order physical model. Click the + button (circled in red).

Change the new schema’s default name to ORDER. Notice that when you’re typing in the schema name, its tab name on the Physical Schemata also changes accordingly—a nice feature.
The order schema is added to the Catalog (I circled the order schema and its objects in red).

Close the schema window. Confirm to rename the schema when prompted.

Creating Order Tables

We’ll now create three tables that model the order: ORDER table and its two subtype tables: SALES_ORDER and PURCHASE_ORDER, in the ORDER schema. First of all, make sure you select the ORDER schema tab, so that the tables we’ll create will be in this schema.
We’ll create our tables as EER diagram (EER = Enhanced Entity Relationship). So, double-click the Add Diagram button.

Select (click) the Table icon, and then move your mouse onto the EER Diagram canvas and click on the location you want to place the first table.

Repeat for the other two tables. You can move around the tables by dragging and dropping.

Next, we’ll work on table1, which we’ll do so using the Workbench’s table editor. We start the table editor by right-clicking the table1 and selecting Edit Table.

Next, we’ll work on table1, which we’ll do so using the Workbench’s table editor. We start the table editor by right-clicking the table1 and selecting Edit Table.
Rename the table by typing in ORDER over table1.

We’ll next add its columns, so select the Columns tab. Replace idORDER column name with ORDER_NO.

Select INT as the data type from the drop-down list.

We’d like this ORDER_NO column to be valued incrementally by MySQL database, so we specify it as AI column (Auto Increment).

AI is a specific feature of MySQL database.

You can also specify other physical attributes of the table, such as its Collation; as well as other advanced options, such as its trigger and partioning (the Trigger and Partioning tabs).

Notice that on the diagram our table1 has changed to ORDER, and it has its first column, ORDER_NO. In the Catalog you can also see the three tables.

The black dots on the right of the tables indicate that they’ve been included in an diagram.

---

Creating your MySQL Database: Practical Design Tips and Techniques

A short guide for everyone on how to structure your data and set-up your MySQL database tables efficiently and easily. How best to collect, name, group, and structure your data Design your data with future growth in mind Practical examples from initial ideas to final designs The quickest way to learn how to design good data structures for MySQL From the author of Mastering phpMyAdmin

If you expand the ORDER folder, you’ll see the ORDER_NO column. As we define the column as a primary key, it has a key icon on its left.

Back to the table editor, add the other columns: ORDER_DATE and ORDER_TYPE. The ORDER_TYPE can have one of two values: S for sales order, P for purchase order. As sales order is more common, we’d like to specify it as the column’s default value.
You add the next column by double-clicking the white space below the last column.

In the same way, create the SALES_ORDER table and its columns.

Lastly, create the PURCHASE_ORDER table and its columns.

Create Relationships

We have now created all three tables and their columns. We haven’t done yet with our model; we still need to create the subtype relationships of our tables.
The SALES_ORDER is a subtype of ORDER, implying their relationship is 1:1 with the SALES_ORDER as the child and ORDER the parent, and also the ORDER’s key migrated to the SALES_ORDER. So, select (click) the 1:1 identifying relationship icon, and click it on the SALES_ORDER table and then ORDER table.

Notice that the icon changes to a hand with the 1:1 relationship when you click it to the tables.

The 1:1 relationship is set; the ORDER_NO primary key is migrated and becomes the primary key of the SALES_ORDER table.

Next, create the PURCHASE_ORDER to ORDER relationship, which is also 1:1 identifying relationship.

We have now completed designing our tables and their relationships; let’s save our model as ORDER.mwb.

Generate DDL and Database

The final step of our data modeling in this article is generating the model into MySQL database. We’ll first generate the DDL (SQL CREATE script), and then execute the script.
From the File | Export menu, select Forward Engineer SQL CREATE Script.

Lastly, execute the saved SQL CREATE script. We execute the script outside of MySQL Workbench; for example, we can execute it in a MySQL command console.

You can also confirm that the tables have been created.

Summary

This article shows you how to build a MySQL physical data model visually in MySQL Workbench, and generate the model into its MySQL database.

Source