Diving into Ruby – Toes First – on Windows 7

Posted on November 22, 2010 by Rob Taylor

In an effort to broaden my development reach, and potentially work on a RoR project, I decided to test the development environment of RoR, and see how confusing and frustrating it can be, by setting up the environment by myself, and just using some basic online tutorials to get me started.

Ill document the useful resources that I find in this post, and hope that it will serve as a quick startup guide for true RoR noobs, like myself.

Dev Environment Setup

In my environment, I already have WAMP stack installed … via EasyPHP-3.0, so for this, I did not have to reinstall mysql (though I did have to hook the two together … ill show you).

First, download Ruby and run the installer.
Ruby Download

After reading a bit about the various IDEs (coming from a Dreamweaver PHP/mySQL environment), I chose to install a trial version of RubyMine 3.x, as many users on stackoverflow preferred it as a more complete package.
RubyMine Download

- Run the RubyMine installer, and then start a new project (Rails).  Once you have done this, and named it, you can select the SDK location of Ruby (pathTORuby/bin/ruby.exe), and then the Gems/Rails will get downloaded/installed by itself.

- Select mySQL as the DB type to setup.  It will then load the mySQL plugins needed when you select the instructed installer bar in the interface (you’ll see it).

- In this current context, you will probably get errors on run, since you have not hooked mysql up to the Ruby environment.  Close out RubyMine.

Go to the EasyPHP folder, and search for libmysql.dll  – Find that file, copy it, and paste it to the [RUBY]/bin/ directory of your ruby install.

Now, open RubyMine again, and hit run… if your mysql2 gem is installed, then this should all start correctly, and you should be directed to a browser (localhost) address that you can stick in any browser, and you will see your default Ruby Install homepage is up and running – SUCCESS!!

Here is the error message I was getting earlier, before fixing the mysql issues, for your reference:

D:\ProgramFiles\Ruby192\bin\ruby.exe -e $stdout.sync=true;$stderr.sync=true;load($0=ARGV.shift) C:/Users/Rob/RubymineProjects/test1/script/rails server -p 3000 -b 127.0.0.1 -e development
D:/ProgramFiles/Ruby192/lib/ruby/gems/1.9.1/gems/mysql2-0.2.6-x86-mingw32/lib/mysql2/mysql2.rb:2:in `require': 126: The specified module could not be found.   - D:/ProgramFiles/Ruby192/lib/ruby/gems/1.9.1/gems/mysql2-0.2.6-x86-mingw32/lib/mysql2/1.9/mysql2.so (LoadError)
    from D:/ProgramFiles/Ruby192/lib/ruby/gems/1.9.1/gems/mysql2-0.2.6-x86-mingw32/lib/mysql2/mysql2.rb:2:in `<top (required)>'
    from D:/ProgramFiles/Ruby192/lib/ruby/gems/1.9.1/gems/mysql2-0.2.6-x86-mingw32/lib/mysql2.rb:7:in `require'
    from D:/ProgramFiles/Ruby192/lib/ruby/gems/1.9.1/gems/mysql2-0.2.6-x86-mingw32/lib/mysql2.rb:7:in `<top (required)>'
    from D:/ProgramFiles/Ruby192/lib/ruby/gems/1.9.1/gems/bundler-1.0.7/lib/bundler/runtime.rb:64:in `require'
    from D:/ProgramFiles/Ruby192/lib/ruby/gems/1.9.1/gems/bundler-1.0.7/lib/bundler/runtime.rb:64:in `block (2 levels) in require'
    from D:/ProgramFiles/Ruby192/lib/ruby/gems/1.9.1/gems/bundler-1.0.7/lib/bundler/runtime.rb:62:in `each'
    from D:/ProgramFiles/Ruby192/lib/ruby/gems/1.9.1/gems/bundler-1.0.7/lib/bundler/runtime.rb:62:in `block in require'
    from D:/ProgramFiles/Ruby192/lib/ruby/gems/1.9.1/gems/bundler-1.0.7/lib/bundler/runtime.rb:51:in `each'
    from D:/ProgramFiles/Ruby192/lib/ruby/gems/1.9.1/gems/bundler-1.0.7/lib/bundler/runtime.rb:51:in `require'
    from D:/ProgramFiles/Ruby192/lib/ruby/gems/1.9.1/gems/bundler-1.0.7/lib/bundler.rb:112:in `require'
    from C:/Users/Rob/RubymineProjects/test1/config/application.rb:7:in `<top (required)>'
    from D:/ProgramFiles/Ruby192/lib/ruby/gems/1.9.1/gems/railties-3.0.3/lib/rails/commands.rb:28:in `require'
    from D:/ProgramFiles/Ruby192/lib/ruby/gems/1.9.1/gems/railties-3.0.3/lib/rails/commands.rb:28:in `block in <top (required)>'
    from D:/ProgramFiles/Ruby192/lib/ruby/gems/1.9.1/gems/railties-3.0.3/lib/rails/commands.rb:27:in `tap'
    from D:/ProgramFiles/Ruby192/lib/ruby/gems/1.9.1/gems/railties-3.0.3/lib/rails/commands.rb:27:in `<top (required)>'
    from C:/Users/Rob/RubymineProjects/test1/script/rails:6:in `require'
    from C:/Users/Rob/RubymineProjects/test1/script/rails:6:in `<top (required)>'
    from -e:1:in `load'
    from -e:1:in `<main>'

Process finished with exit code 1
Posted in development | Tagged , , , | Comments Off

Nexus 7000 and IOS OSPF Loop Prevention and Interoperability

Posted on November 18, 2010 by Rob Taylor
Introduction:

With the introduction of rfc2328, or OSPFv2, the path selection criteria for external or summary routes changed.

Specifically, the new changes call for preferring a non-backbone path over a backbone(area 0) path for the prefix. Previously, we relied on cost to determine path selection, without regard to whether it was a backbone or non-backbone path.

IOS  has always treated rfc1583 as the default behavior for path selection,  and as support for rfc2328 was added, IOS added a toggle to prefer this  new method of path selection, but continued to keep rfc1583 behavior set  by default.

NX-OS, however, was launched with rfc2328  only behavior by default, and then to conform with RFC specs, added a command to make it optionally rf1583 compliant.

Problem Statement:

This  difference in default behavior can lead to ospf loops, where you have  some devices pointing to one path as the shortest path, and other  devices pointing to a different path as the shortest path.

The scenario below illustrates this problem:

ASBR1----area0-----(e3/7)ABR(e2/10)----area100----(G0/0)rtrB-----area100---ASBR2

ABR is an n7k, and rtrB is an IOS router (2800 in this case). Both ASBR1 and ASBR2 redistribute a route, same prefix (192.168.0.0/16) into OSPF.

With their default configurations, the following takes place in the routing tables:

ABR# show ip route 192.168.0.0

192.168.0.0/16, ubest/mbest: 1/0 *via 10.0.0.2, Eth2/10, [110/160], 00:03:00, ospf-loop, type-1

------------------------------------------------------------------------------------------------------

rtrB#show ip route 192.168.0.0 Routing entry for 192.168.0.0/16, supernet Known via "ospf 1", distance 110, metric 25, type extern 1 Last update from 10.0.0.1 on GigabitEthernet0/0, 00:20:40 ago Routing Descriptor Blocks: * 10.0.0.1, from 2.2.2.2, 00:20:40 ago, via GigabitEthernet0/0 Route metric is 25, traffic share count is 1

As you can see, the IOS router points out g0/0 to the n7k, and the n7k(ABR) points out e2/10 to rtrB.  This is a loop!

Now, we will turn on the rfc1583compatibility command on the n7k(ABR) and it will allow us to use the metric for our decision, like the IOS router is doing.

ABR(config)# router ospf loop ABR(config-router)# rfc1583compatibility ABR# show ip route 192.168.0.0

192.168.0.0/16, ubest/mbest: 1/0 *via 10.10.10.1, Eth3/7, [110/24], 00:00:05, ospf-loop, type-1 ABR#

---------------------------------------------------------------

rtrB#show ip route 192.168.0.0 Routing entry for 192.168.0.0/16, supernet Known via "ospf 1", distance 110, metric 25, type extern 1 Last update from 10.0.0.1 on GigabitEthernet0/0, 00:30:03 ago Routing Descriptor Blocks: * 10.0.0.1, from 2.2.2.2, 00:30:03 ago, via GigabitEthernet0/0 Route metric is 25, traffic share count is 1

As you can see, if all the ospf routers in this domain are configured to run according to the same rfc mode, then we do not experience these same loops, as the complete domain is consistent in what it considers to be the shortest path.

Configuration:

On NX-OS, you can use the "rfc1583compatibility" command to make the device align with default IOS behavior.

On IOS, you can use the "no compatible rfc1583" command to make the device align with default Nexus behavior.

Which ever of the two options you use is your choice, but I will not go into the major design differences here in this post.
Posted in interoperability, loop, lsa, n7k, nexus, nexus_7000, nx-os, ospf, ospfv2, rfc1583, rfc2328, routing | Tagged , , , , , , , , , , | Comments Off

Nexus 7000 ACL logging (OAL)

Posted on November 16, 2010 by Rob Taylor

Introduction:

 

As many customers have opened TAC cases about logging access-lists on the n7k platform, I have put together this quick configuration guide and explanation to serve as a reference to eliminate some of the confusion.

 

Keep in mind that ACL logging in NX-OS does not look like traditional IOS acl logging.  We do not see a log message EVERY time there is an acl hit.  Instead we see hit notifications sent at specific intervals.

 

Optimized Access-list Logging is a feature that was introduced on the 6500 platform a while back.  The Nexus 7000 uses this same infrastructure to keep the CPU protected from ACL logging that customers may implement.

 

"OAL provides hardware support for ACL logging...OAL permits or drops packets in  hardware and uses an optimized routine to send information  to the RP to generate the logging messages"

- 6500 configuration guide  http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/acl.html#wp1090858

 

On the 6500/7600, OAL was optional, and you could still use CPU intensive acl logging if desired (on by default).

On the Nexus 7000, OAL is the only option for ACL logging.

 

So now lets look at the n7k specific implementation of ACL Logging, or OAL.

 

My setup uses the following topology:

 

host(10.0.0.2)---(10.0.0.1)e2/10__N7k__e2/11(11.0.0.1)---(11.0.0.2)host

 

Two access lists are applied to the same interface, e2/10.  TEST is applied inbound, and TEST2 is applied as outbound.

interface Ethernet2/10
  ip access-group TEST in
  ip access-group TEST2 out
  ip address 10.0.0.1/30

 

IP access list TEST
        10 permit ip any 11.0.0.2/32 log
        20 permit ip any any

IP access list TEST2
        10 permit ip any 10.0.0.2/32 log
        20 permit ip any any

 

 

 

 

Configuration:

 

By default, if you have an access-list configured with the log parameter, you will not see any logs in the buffer.  However, you will be able to see them in the OAL cache (this output comes after sending 5 pings with source 10.0.0.2 to 11.0.0.2):

 

RP_7k2# show log ip access-list cache
Source IP         Destination IP    S-Port  D-Port    Interface   Protocol   Hits
--------------------------------------------------------------------------------
11.0.0.2         10.0.0.2           0       0         Ethernet2/11     (1)ICMP    5
10.0.0.2         11.0.0.2           0       0         Ethernet2/10     (1)ICMP    5

Number of cache entries: 2
--------------------------------------------------------------------------------
RP_7k2#

 

* Note that the above output shows the "Interface" value as Ethernet2/11  for the first flow.  This is the ingress interface for that packet, not  the interface where the ACL was applied.

 

The cache entry persists while the flow is active, but the hit counters are cleared at a set interval (configurable).  This interval is also used to set frequency of the actual log messages that are displayed.  In other words, once the flow is created, you will receive a log message every [interval] seconds with an update showing the current hit counters for that flow (while that flow is still active in the cache).

 

 

By default, the following settings are applied, which do not have to be changed.

 

RP_7k2(config)# show log ip access-list status
Max flow        = 8000
Alert interval  = 300
Threshold value = 0
RP_7k2(config)#

 

 

OAL specific parameter configuration:

 

logging ip access-list cache {{entries num_entries} | {interval seconds} | {threshold num_packets}}

 

entries - sets the (Max Flow) number of cache entries;

interval - sets the interval between logging messages for each flow, and the timeout value for the flow;

threshold - sets the hit counter value at which we start logging this acl cache entry;

 

Default OAL values are sufficient to get the logging enabled.

 

Required non-default changes for logging

 

switch(config)# logging level acllog 3

switch(config)# acllog match-log-level 3

switch(config)# logging logfile [name] 3

As shown above, the logging level for the "acllog" facility must be configured to be greater than or equal to the "acllog match-log-level" setting, and the "logging logfile" severity must be equal to or greater than that setting as well.  Otherwise, the log messages do not show up in the logs.  I used the value of 3 by choice, but is not a required setting.

 

Once this is configured, you can see the logs show up as desired:

 

RP_7k2# show log logfile

2010 Nov 16 18:08:14 RP_7k2 %ACLLOG-3-ACLLOG_FLOW_INTERVAL: Source IP: 10.0.0.2,
Destination IP: 11.0.0.2, Source Port: 0, Destination Port: 0, Source Interface
: Ethernet2/10, protocol: "ICMP"(1),  Hit-count = 5
2010 Nov 16 18:08:17 RP_7k2 %ACLLOG-3-ACLLOG_FLOW_INTERVAL: Source IP: 11.0.0.2,
Destination IP: 10.0.0.2, Source Port: 0, Destination Port: 0, Source Interface
: Ethernet2/11, protocol: "ICMP"(1),  Hit-count = 5


RP_7k2#

 

As you can see, each active flow updates the log with the number of hits during the current interval, and will continue to do so while the flow is active.

 

And that's it!  The settings can be tweaked to match your needs, but you now have acl logging, without impacting the cpu!

Posted in access-list, acl, n7k, nexus, nexus7000, oal, security | Comments Off