Метод для ubuntu:
cat >> /etc/network/options
ip_forward=yes

Метод для любой линухи:
cat >> /proc/sys/net/ipv4/ip_forward
sysctl net.ipv4.ip_forward = 1

Метод изменения значения на лету:
sysctl -w net.ipv4.ip_forward=1
или
echo 1 > /proc/sys/net/ipv4/ip_forward

Vamos a ver un poco mas a fondo el routing de mvc, desde mvc proponen un modelo ‘controlador’ -> ‘action’ -> ‘parametros’ al viejo estilo de get, a primera vista parece poco flexible y se nos ocurren aplicaciones pero siempre dependiendo de escribir las pertinentes acciones en los controladores, ademas por cada nueva accion hay que escribir su correspondiente vista …. no pinta muy bien visto asi.

Propongo el siguiente ejemplo, una web que tiene de coches, motos y furgonetas de ocasion, el ejemplo lo he centrado en los coches, al final deberia tener el mismo controlador y action para los tres casos y en cualquiera de los modelos que tengamos en catalogo, estariamos hablando de una hipotetica pantalla que nos listaria los coches disponibles con una marca y modelo concretos:

Vamos al lio: nos creamos un proyecto mvc

Abrimos el archivo global.axa.cs

Nuestra intencion es desde un mismo metodo action del controlador ‘Listado’ poder atender todas las peticiones, asi los parametros de entrada van por delante del controlador siendo ’sector’->’marca’->’modelo’->’controlador’, en el global.axa.xs queda asi:

Lo siguiente es crearnos el controlador  ‘Listado’ con el metodo Index, es el invocado desde global.axa por defecto y es donde esperamos los atributos ’sector’, ‘marca’ y ‘modelo’

Ahora ya podemos crearnos la vista, primero crear una carpeta con el nombre ‘Listado’ y dentro creamos las vista Index (coincidente con el nombre del action), con el viewData podemos devolver el tag titulo que antes informamos en al action.

Ahora ya solo nos queda probarlo, mejor compilar antes y sobre el puerto de servidor que nos proponga nuestro vs ponemos ‘/coches/alfa/147/listado’, ahora ya estamos viendo la potencia del mvc, podemos poner los parametros donde queramos, en este caso por delante del controlador , p.ej

Pero tambien podemos usar el clasico paso de parametros por get, para este caso solo es necesario modificar el controlador, en este caso vamos a añadir los parametros ‘orden’ y ‘pag’:

Tb necesitamos modificar la vista para recibir los parametros como lo hicimos la anterior vez, y la url podria acabar siendo algo asi ‘coches/alfa/147/Listado?orden=precio&pag=1′, p.ej:

Ya esta, con esto tendriamos por un lado el listado de los vehiculos y por otro el control del orden y la paginacion, todo centralizado en el mismo controlador y action al permitir parametros de entrada opcionales,  mas compacto y limpio dificil.

Click the link to be taken to the Mt Sierra Student Services Blog!

http://mtsierracollege.mtsierra.edu

Let’s talk about some issues that arise when we scale an OSPF internetwork up to a large size. As usual when it comes to scalability, there are three issues involved:

• Bandwidth
• RAM
• CPU

First, as the internetwork grows, there are more routers. Recall that with link-state protocols such as OSPF, every router’s LSA (Link State Advertisement) is flooded throughout the internetwork. Obviously, the more routers, the more LSAs must be flooded, which results in more LSU (Link State Update) packets, consuming more bandwidth on the links.

Second, as the LSAs are flooded, each router makes a copy of each LSA, which it keeps in its LSDB (Link State Database). Therefore, the more routers, the larger will be each router’s LSDB, and a larger LSDB requires more RAM to store it. Also, since there are a lot of prefixes, the resulting routing table will be large, requiring even more RAM.

Third, every time a router’s LSDB changes, the router runs Dijkstra’s SPF algorithm to generate its revised routing table. The larger the internetwork, the larger the LSDB, and the more frequently it’s likely to be changing. Thus, each router is running SPF more often on a larger LSDB, consuming more CPU cycles.

The bottom line is that since bandwidth, RAM, and CPU cost money (and we don’t have infinite money) there is some limit to how large an OSPF autonomous system can grow. There are two solutions to this scalability problem

1. Limit OSPF to small internetworks (bad idea!)
2. Modify OSPF to enhance its scalability (good idea!)

Of the two options, the latter was used, and we call it “multi-area OSPF”. What we do is divide the OSPF autonomous system into regions called “areas”. An example of a multi-area OSPF topology is shown here:

Here’s how it works

A router that lies completely within an area is called an “internal router”. Internal routers, such as R1, know the entire topology for that specific area (in R1’s case it’s Area 1). Using SPF on its LSDB, R1 builds its routing table by calculating the best path from itself to any prefix within Area 1. At this point, R1 knows the best route to all prefixes within Area 1. Likewise, internal routers R3 and R5 calculate their routing tables for Area 0 and Area 2, respectively.

A router that is attached to more than one area is called an Area Border Router (ABR), and it maintains an LSDB for each area to which it is attached. R2, for example, is an ABR which connects Area 0 and Area 1. R2 runs SPF on its Area 0 and Area 1 LSDBs, and the results go into its routing table. Thus, R2 knows the best path from itself to all prefixes within Area 0 and Area 1. In addition, R2 now advertises the prefixes that lie within Area 0 into Area 1, and vice-versa. Note that only the prefixes and their metrics are advertised, not the existence of individual routers within an area. Likewise, R4, the ABR between Area 2 into Area 0, advertises prefixes between them.

For reasons of fault-tolerance, it’s possible that there could be two or more ABRs joining two areas. Since each ABR advertises the cost for each prefix from its perspective, the routers in the area receiving the advertisements can make optimal routing decisions about the prefixes that lie in the other area. At this point, all routers know the best route to all prefixes within the areas to which they are attached, and to the prefixes within the adjacent areas.

Furthermore, the Area 1 prefixes that R2 is sending into Area 0 are flooded over to R4, which then floods them into Area 2. As a result, all routers in Area 2 know about the prefixes in Area 1. This happens in the opposite direction, as well, and when the flooding has completed, all routers will know about all of the prefixes within the entire OSPF autonomous system. Because it’s just the prefixes and their costs that are being advertised between areas, and not detailed topology information, this requires less bandwidth, RAM and CPU than if it were all one big OSPF area, with all routers knowing everything about the topology.

In the next installment, we’ll continue our discussion of multi-area OSPF, including some techniques to further increase the scalability.

Author: Al Friebe

It was definitely a weekend revolving around the new tool (understandably), from the pickup/delivery organising on Friday, the assembly (and getting it into the shed) Saturday, and commissioning it with some real tasks on Sunday.

If you were wondering how I was going to fit a 2.5m x 1m tool in my workshop, well, you were not the only one!  With a large pry bar!  Archimedes once remarked (paraphrasing) that with a firm place to stand he could move the Earth (with a long-enough lever that is).

Makin' a Hole

Clearing space was a combination of moving the jointer to where the router table was, removing the corner bench and in future the sanders will (potentially) be on roll-outs from under the Torque, and the router table met an untimely end, with the top being amalgamated with the TWC.  A hole was born.

The Torque arrives in its new home

I did try the TWC along the back wall, but lost too much access around the unit.  The MDF top has yet to be added – will do so some time this week.

That 1300mm arm is huge – I’m going to fit the 600mm (or 900mm) arms for the majority of the jobs, and the 1300 will get used only when I need that much extension.  For some workshops it probably would remain, but that is the one compromise on space I will have to make.  Sure looks nice here (by the end of the weekend it sure ended up rather dusty!)

Adding the Router Table

Here I have added the router table (with Incra Positioner/Fence) to the end where there is some dead space (because of the way the tools are carried on the left side of the arm), so this really utilises that area. I’ve moved the bandsaw further back so I have adequate access to the router table, and it isn’t hard to swing the entire unit out from the wall if I need more in-feed area.  Since this photo, I have also replaced the first module of the top with a plain cast-iron wing – it won’t be a two-router table now (well it is, but one is overhead), and I’ve shortened the cast iron top to 3 wings from the original 5.  The MDF of the rest of the bed will be at the same height, so there is no shortage of area for the positioner now!  At 2.5m long, this may be the largest router table in the world!

The clamp roof

The clamp wall was a problem, both getting access to the clamps, and also having them interfere with the X axis of the TWC, so they have been moved to the roof.  If the clamps are any good, then it won’t be a problem where they are!  Added benefit – partway through a clamp-up, if I need another I just reach up!

Temporary Triton Mount

One minor glitch I had (and it will be rectified by the end of the week), is the router mount had support posts for a Makita (I think), and not the Triton – the Triton needs both a larger diameter and a longer post.  Converting the Triton to fit the table took a few seconds, as did reverting it back to standard operation.  I was surprised just how easy it was – a single circlip.  So that I could make use of the router before the parts arrive, I added the old Triton quick-release plate from the original Triton router table.  The setup is rather flimsy like this, but it got the job done.

Oven Doors

First job was the oven doors for the kid’s kitchen – setting the stops for the size of the opening, then routing it out.  I also used the same method for cutting hinge mortises.

Oven Shelf

The second job was creating the shelf in the oven.  Rather than just a plain shelf, I didn’t want the inside of the oven to look like a cupboard, so I cut parallel slots through using a 1/2″ straight router bit, and moved the whole setup 30mm for each pass.  Again, something that could have been done other ways, but this was a very simple (and accurate) method.  It’s like using a machine with a built-in, adjustable jig.

So that was all I had time for in the end, but already it has been demonstrating for me just how functional the concept is.

Google Vs Bing ; Keep It Simple Smarty!!

Like a midnight owl, trying to keep my eyes open while browsing through the search engine index of web page results, something Clicked me.

While Google is my Best Friend forever and eternity, Microsoft has made an innovative come back with its latest Search Engine “Bing”. The day I heard about its launch on B.B.C  [British Broadcasting Corporation], I intuitively concluded that no matter how good it might be, it still won’t be able to grab the market from Google in full. This is the same principle that Microsoft had applied to its Products especially the Windows OS. The market of Apple has also been growing esp. in Europe and America yet Windows remain the most common household OS, as I would put it. Once people are accustomed to something, it takes a while to change their attitude, adaptation and attachment with something. It’s a huge Persuasion Game and Believe ME it’s Hard.

Still I find myself quite quick and sudden to make the leap to Bing in certain cases. My Love for Google hasn’t restricted me to explore and utilize other services like Bing. I am not sure if others agree with me on this though.

If I have to search for “Images” for instance, I would switch to Bing and prefer it over Google.  While searching for an article on Asp.net Routing on Google right now and not finding suitable results, I had a huge realization that I should try Bing instead for very solid and logical reasons. Though my reasons might seem to some as Blind psychology rather than logical, I would still stick to it.

Anything Microsoft, simply let Microsoft find it for you since it would index all its stuff properly and efficiently. My logical reasoning did prove correct when I was returned a number of results all matching my search criteria perfectly.

So, next time if I need to search for anything Microsoft, I would simple keep my love for Google aside for a while and try paying Microsoft’s Bing a Visit. However, in real time though it sure seems that both are competing neck to neck and producing nearly identical results.

Let me know what you think about this. Until that time…..Happy Visiting!!!

Share It!

Wired networks are traditionally viewed as a unicast medium: packets are sent from A to B. Because the underlying medium can have a degree of sharing (e.g. multiple hosts connected to the same Ethernet hub), steps must be taken to avoid interference between concurrent senders (e.g. CSMA).

In a wireless network, the medium is shared: any hosts in range of a radio transmission can receive it. If the goal is to use a traditional unicast routing protocol over a wireless link, this makes interference between senders a more challenging problem (e.g. as discussed in the MACAW paper). However, rather than viewing broadcast as an inconvenience we need to work around, the broadcast nature of wireless can also be leveraged to design new protocols that would be infeasible for a wired network.

A nice example of a broadcast-oriented protocol for wireless is “ExOr: Opportunistic Multi-Hop Routing for Wireless Networks“. In a traditional routing design, a sender chooses the next hop that should receive a packet, and then unicasts the packet to that destination. In ExOr, a sender broadcasts a batch of packets to a group of nodes simultaneously. The set of batch recipients coordinate to try to ensure that each packet in the batch is forwarded onward. The recipient of a packet is only chosen after the packet is sent, which allows ExOr to “opportunistically” take advantage of links that have high loss rates. ExOr assumes that node reception probabilities are mostly independent and mostly decrease with distance — both of which are probably pretty reasonable assumptions.

Design

The source collects a batch of packets destined for the same host, and then chooses a forwarding list for the batch. The forwarding list is a list of nodes, sorted by the expected cost of delivering packets from that node to the eventual destination node. The cost metric is similar to ETX (expected number of transmissions required to send the packet to the destination via unicast, including retransmissions); unlike ETX, it only considers the forward delivery probability. While it would be possible to including all possible recipient nodes in the forwarding list, this would increase the coordination cost among the forwarders, so ExOr only includes “likely” recipients in the list (estimated 10%+ chance of receiving a broadcast packet).

Each packet contains a batch map, which holds the sender’s estimate of the highest priority (according to the cost metric) node to have received each packet in the batch. When a node receives a packet, it uses the packet’s batch map to update its local batch map. This means that batch map information propagates through the nodes, carrying information about packet reception from high priority nodes to lower priority nodes.

After the source broadcasts a batch, each member of the forwarding list broadcasts, ordered by descending priority (ETX value). Each node broadcasts the packets it received, along with its updated batch map. Nodes coordinate to schedule their transmissions to try to avoid interference (e.g. by estimating when each node’s expected transmission time is, according to ETX value and batch map contents). The protocol continues cycling through the nodes in priority order. At the end of each cycle, the ultimate destination broadcasts its batch map 10 times; at the beginning of each cycle, the source resends packets that weren’t received by any node (by observing batch map contents). The ExOr scheme stops when 90% of the packets in a batch have been transferred, and uses a traditional routing policy to deliver the remainder of the batch.

Discussion

Overall, ExOr is a really neat idea. That said, it is at best a special-purpose solution, because of the high latency it incurs for batching and multiple transmission rounds. Similarly, the need for a split TCP proxy is pretty ugly. A complete solution to wireless routing would perhaps adaptively switch between latency-oriented and bandwidth-oriented routing techniques, depending on the nature of the traffic.

It seems arbitrary to me that ExOr works on a batch-by-batch basis—that almost seems like establishing a new TCP connection for each window’s worth of data. The amount of useful work done in each transmission round decreases, until the protocol imposes an arbitrary cutoff at 90% and switches to a traditional routing protocol. Instead, wouldn’t it be more sensible for ExOr to allow new packets to be inserted into the batch as the destination confirms the delivery of packets? This would essential emulate the “conservation of packets” principle from the Van Jacobson paper.

I Guess this should suffice for a fair understanding of the routing protocols mentioned.

Nations are built not with bricks and stones but with the capacity to create and apply knowledge. The result of knowledge creation and application in manufacturing and management practices is well demonstrated by Japan. Today we are witness to many industrialized economies that are strengthening their manufacturing activities simply by adopting these techniques.

The distinguishing characteristics associated with Japanese manufacturing techniques include an emphasis on designing and redesigning processes to optimize efficiency and a strong commitment to quality.

The manufacturing techniques that Japanese companies practice provide a competitive advantage and outstanding economic performance. The key for success is an understanding of the broad context of manufacturing culture, infrastructure and environment. These sound manufacturing and business techniques created and adopted by leading Japanese manufacturers have turned out to be the secret of their market leadership in many industries.

Following are a few of these concepts, which can help in managing any business set-up in a better way:

• Kaizen is one such technique, which in Japanese means ‘improve.’ This is commonly recognized as practices focusing on continuous improvement in manufacturing activities, business activities in general, and even life in general, depending on interpretation and usage. By improving standardized activities and processes, Kaizen helps in eliminating waste.
• Another management Japanese technique is the 5-S. It is a technique used to establish and maintain quality environment in an organization. It has five elements: Seiri (sorting out useful and frequently used materials and tools from unwanted and rarely used things); Seiton (keeping things in the right place systematically so that searching or movement time is minimized); Seiso (keeping everything around you clean and in a neat manner); Seiketsu (standardizing the above principles in everyday life) and Shitsuke (inculcating good habits and practicing them continuously). The 5-S practice helps everyone in the organization to live a better life.
• Kanban and ‘Just in Time’ are two other practices in inventory management practices that were pioneered by the Japanese automobile manufacturers, such as Toyota. Quality improvement, on the other hand, is the result of lower proportion of component scrap since the components spend less time in the supply chain.
• Poka-yoke is a process improvement focused on training of workers for mastering the increasingly complicated tasks to selectively redesign the tasks so they could be more easily and reliably mastered. It involves designing a foolproof process to eliminate the chance of errors.
• Jidoka is a practice by means of which an individual worker runs several machines simultaneously. Japan thus designs such machines that eliminate both error and the need for constant supervision.
• Muda is another technique that reduces wasteful activity in service processes. It ensures process efficiency and effectiveness.
• Mura curiously combines rigidity and flexibility and thus teaches service process improvement.
• Reducing Muri means reducing physical strain. In services process improvement, Muri applies to convoluted and unnecessary routings, physical transfer, and distances paper files may have to travel for a process to complete.
• Genchi Gembutsu means going to the actual scene (genchi) and confirming the actual scene (gembutsu). Observation of service processes at the point where it is actually delivered may unearth a host of problems such as lack of training, unnecessary steps, or a number of other areas that would benefit from small but significant process improvement ideas.

This is a glimpse of manufacturing techniques that Japan has so intellectually created and so profoundly practiced in its manufacturing systems that even with no natural resources, it has acquired the status of one of the most industrialized nations. Can we learn from Japan?

My Consultancy–Asif J. Mir - Management Consultant–transforms organizations where people have the freedom to be creative, a place that brings out the best in everybody–an open, fair place where people have a sense that what they do matters. For details please visit www.asifjmir.com, Lectures, Line of Sight.

La modificacion del routing en mvc es el alma de la aplicacion, de verte recortado a tres niveles puedes tener los que quieras, si jugar con los parametros de entrada no te sirvio, aqui podemos ver un ejemplo mas claro.

La configracion inicial dentro del global.axas.cs->RegisterRoutes te propone la particion en {controller}/{action}/{id}, por ejemplo: http://www.pepe.com/deportes/futbol?categoria=reina&equipo=azul&zona=vip , donde el controlador es ‘deportes’, action es ‘futbol’ y los parametros son ‘categoria, equipo y zona’

Ok, y si yo necesito una carpeta entre controlador y action el sitio podemos hacer algo asi: {controller}/{sport}/{action}/{id}, despues puedes hacer con tu variable sport lo que quieras.

Podeis ver el tutorial oficial de microsoft con un ejemplo de routing

Free Seats are back! AirAsia, the world’s best low cost airline is today giving away 1 million free seats*, to over 70 hot destinations including China, India, Taiwan, Indonesia, Thailand, Singapore and many more across our extensive network of over 130 routes; stretching across 20 countries.

The free seats promotion kicks off from 11 – 15 November 2009 (booking period) for the travel period from 1 May – 30 October 2010. Guests may log on to www.airasia.com or mobile.airasia.com to find out more about these exciting great deals.

AirAsia’s Regional Head of Commercial, Kathleen Tan said, “To usher 2010, this is the biggest and most exciting promotion of the year. With no fuel surcharge, and no administration fee, it’s a real deal, offering fantastic value to our guests. When the economy is tough, people seek cheaper traveling options which offer them better value for money and there is no better option than flying with AirAsia for Free! This is also our gesture of saying a big thank you to our guests and the public who supported and contributed to AirAsia’s success. Without them, we would not have been conferred the recent “Airline of the Year 2009” award from the Centre for Asia Pacific Aviation (CAPA), flying over 80 million guests to date.”

“AirAsia always observe the importance of low fares to ensure everyone can fly; and bringing back our highly popular free seats promotion will give our guests the greatest value ever. What’s more? To compliment the free flights, GoHoliday, AirAsia’s one stop travel portal is also offering sizzling deals and fantastic packages, including “Free Rooms” for over 180 Asia Pacific hotels online at http://goholiday.airasia.com. With this incredible offer, guests can plan their holidays ahead to enjoy great bargains, take this opportunity to be creative and map their holiday routing via AirAsia’s ten hubs (Kuala Lumpur, Kota Kinabalu, Bangkok, Phuket, Bandung, Jakarta, Surabaya and Bali, Penang and Johor) across our network at ultra low fares. For instance, guests from Australia, Europe or the Middle East may explore exotic ASEAN and beyond to some of the world’s most popular island resorts such as Bali, Phuket, Langkawi, and vice versa. With these great deals, AirAsia’s guests with huge appetite for travel will be spoilt for choice as we not only cater to the leisure market but also the adventure seekers, diving enthusiasts, historical and heritage explorers, shopaholics, and keen golfers all within our vast route network.” concluded Kathleen.

Guests can fly from Kuala Lumpur to domestic destinations such as Penang, Kota Kinabalu, Kuching and many more from as low as RM6 (All In Fare)*. Popular international destinations such as Jakarta, Bali, Yogyakarta, Bangkok, Phuket and even Tianjin are offered from as low as RM25 (All In Fare)*.
The best part is that, AirAsia’s long haul affiliate, AirAsia X recently launched routes such as Abu Dhabi, and Chengdu are also offered within the same period with special fares from as low as RM 99.00* (All In Fare)* only. AirAsia X highly in demand “Kangaroo Routes” to Australia such as Gold Coast, Melbourne and Perth are offered from as low as RM149.00 (All In Fare)* and the popular London route is also on offer from as low as RM499 (All In Fare)*.

Promotional seats are limited and available on first-come, first-served basis and made exclusively online via www.airasia.com and mobile.airasia.com.

Stay tuned! Follow AirAsia on Twitter, Facebook, and AirAsia’s Blog where we will provide real time updates on our latest promotion.

Source  :  www.tourismtravel.com

One of the challenges faced in networking research and education is the difficulty of accurately recreating a network environment. Production routers are implemented as hardware devices, but designing and fabricating a new hardware design for research or teaching is very expensive. Modular software routers like Click enable research and education on routing in software, but don’t allow experimentation with hardware and physical-layer issues.

NetFPGA aims to rectify this, by providing an easy-programmable hardware platform for network devices (NICs, switches, routers, etc.). Users interact with NetFPGA remotely, uploading programs that configure FPGAs on the device appropriately, and then observing the results. The initial version of NetFPGA didn’t have a CPU: instead, software to control the device runs on another computer, and accesses hardware registers remotely (using special Ethernet packets that are decoded by the NetFPGA board). The second version of NetFPGA has an optional hardware CPU.

Discussion

This seems like a pretty incontrovertible “good idea.” One potential question is how the performance of an FPGA-based router compares to that of realistic production hardware — I’d suspect that NetFPGA-routers occupy a middle ground between software-only routers (easy to develop, poor performance) and production routers (difficult to program and expensive to fabricate, but good performance).

Rodger Foster, our senior Cisco instructor, reviews how multiple gateways are used to provide redundancy in the network. 

Wow, been a while since I blogged anything.  I’ve honestly been intending on opening up a new blog site that isn’t hosted on wordpress (using my own domain, etc) but just haven’t gotten around to it. So I’ll post this here and then move it when I finally get around to setting up the new blog.

The issue of this post is really a gut-level demo of how to unit test routes. I know that MVC Contrib offers some good helpers for doing it, but I was recently preparing an ASP.Net MVC class and I wanted a way of showing the students exactly what goes into the routing engine’s logic, and I felt that manually setting up testing was a good way to walk them through it.

In order to maximize reuse, and reduce code and so on, I chose to create an abstract base class that handled all the wiring of routes and encapsulated a few common operations critical to testing.   The base class is intended as the base of your test class, and so whatever classes you’re testing routes with can inherit from it.  Much of the concepts used in creating this class are thanks to Steve Sanderson’s wonderful Pro ASP.Net MVC book by apress.

Why that and not extension methods?  Well, I simply wanted to have more control over the flow of logic to let each test be more focused. 

Without further ado…

Routing, as you may know, involves both inbound and outbound steps.  Inbound routing happens when the system wants to take a URL that someone’s trying to surf to, and turn it into an object representing the routedata associated with that URL (e.g. info about the controller, action, any input params, etc).

Outbound routing is the opposite, generating URLs based on a given route data object.  Bidirectional testing is critical.  This abstract class supports both, using the Moq framework. 

I’ll cover usage of my class for now, and save an understanding of what my class is doing for another post (though I think it should be pretty apparent; there’s not much magic in there). 

To use this class, you just have to inherit from it, and implement one abstract method. 


[TestClass]
public class MyRouteTests : RouteTestBase
{
protected override void RegisterRoutes(System.Web.Routing.RouteCollection cfg)
{
MvcApplication.RegisterRoutes(cfg);
}
}

that override lets you customize the means by which your app registers its routes.  In htis case, my demo app was using the static method provided by the default MVC template, but obviously I could use other means if needed.

Once I’ve done that, I would want to setup a test for an inbound route like so:


[TestMethod]
public void SlashGoesToHomeIndex()
{
//Arrange
string path = "~/";

// Assert
CoreInboundUrlAsserts(data, "home", "index");
}

Which (if you look at the base class) asserts that my route configuration returned a route data object, an dthat route data object mapped to the HomeController’s Index action.

Doing a simple outbout route test is similarly straightforward:


[TestMethod]
public void HomeIndexGoesToSlash()
{
//Arrange
string expected = "/";
var data = new { controller = "home", action = "index", id = "" };

// Assert
Assert.AreEqual(expected, virtualPath.VirtualPath);
}


And finally, the whole base class looks like this:


public abstract class RouteTestBase
{
protected const string GET = "GET";
protected const string POST = "POST";

protected void CoreInboundUrlAsserts(RouteData data, string controller, string action)
{
Assert.IsNotNull(data, “NULL Route data was returned”);
Assert.IsNotNull(data.Route, “No route was matched”);
Assert.AreEqual(controller, data.Values["controller"].ToString(), true, “Wrong controller”);
Assert.AreEqual(action, data.Values["action"].ToString(), true, “Wrong action”);
}

protected RouteData GetRouteData(string path)
{
return GetRouteData(path, GET);
}

protected RouteData GetRouteData(string path, string httpMethod)
{
RouteCollection cfg = new RouteCollection();
RegisterRoutes(cfg);
var ctx = MakeMockHttpContext(path,httpMethod);
return cfg.GetRouteData(ctx.Object);
}

protected abstract void RegisterRoutes(RouteCollection cfg);

protected Mock MakeMockHttpContext(string url)
{
return MakeMockHttpContext(url, GET);
}

protected Mock MakeMockHttpContext(string url, string httpMethod)
{
var mockHttpContext = new Mock();
MockRequest(url, mockHttpContext, httpMethod);

// Mock response
MockResponse(mockHttpContext);

return mockHttpContext;
}

protected virtual void MockResponse(Mock mockHttpContext)
{
var mockResponse = new Mock();
mockHttpContext.Setup(c => c.Response).Returns(mockResponse.Object);
mockResponse.Setup(r => r.ApplyAppPathModifier(It.IsAny())).Returns(r => r);
MockResponseTestSetups(mockResponse);
}

protected virtual void MockRequest(string url, Mock mockHttpContext, string method)
{
Mock mockRequest = new Mock();
mockHttpContext.Setup(c => c.Request).Returns(mockRequest.Object);
mockRequest.Setup(r => r.AppRelativeCurrentExecutionFilePath).Returns(url);
mockRequest.Setup(r => r.RequestType).Returns(method);
mockRequest.Setup(r => r.HttpMethod).Returns(method);
MockRequestTestSetups(mockRequest);
}

///
/// When overridden in child classses, adds additional setups to customize the request mock
///
///
protected virtual void MockRequestTestSetups(Mock mockRequest)
{
// default do nothing unless the subclass wants to
}

///
/// When overridden in child classses, adds additional setups to customize the response mock
///
///
protected virtual void MockResponseTestSetups(Mock mockResponse)
{
// default do nothing unless the subclass wants to
}

protected VirtualPathData GenerateUrlViaMock(object values)
{
// Arrange
RouteCollection cfg = new RouteCollection();
RegisterRoutes(cfg);
var ctx = MakeMockHttpContext(null);
RequestContext context = new RequestContext(ctx.Object, new RouteData());

// Act
return cfg.GetVirtualPath(context, new RouteValueDictionary(values));
}
}

If you’re using an OpenVPN Server to surf in Ubuntu, maybe you experienced this strange problem : you can connect but you cannot surf !    This how to fix it...

Before we start check your current IP online and save it.

The first thing you have to know is that you shouldn’t use NetworkManager Applet to configure your OpenVPN Connexion, it seems that there’s a problem with vpn connections when using this applet (atleast with Intrepid), you can connect but traffic isn’t redirected correctly, so let’s first make sure you’re correctly  connected ! The best thing to do is to download the configuration files from the OpenVPN Server’s website (just look in the forum if you don’t find it, it’s generally an archive file with a *.conf file and a *.crt file, this last one is the certificate) and use’em directly in a shell console.

Copy the archive content files to

/etc/openvpn/

Type :

cd /etc/openvpn && sudo openvpn yourserver.conf

Enter your login and password and wait till you see :

Initialization Sequence Completed

It means that you’re in.

Now to make sure that you’re not facing a routing problem, just type :

route -n

If you see tunX connections with new IPs, it’s OK you’re connected, if one of your web connected peripheral connections (ethX, athX…) is showing the IP of your OpenVPN Server as a destination you’re correctly routed.

Now try to ping the tunX IP with a gateway, if you’ve got this message :

ping: sendmsg: Operation not permitted

You got the fix ! It’s a SIMPLE FIREWALL PROBLEM !

To solve it, you have to edit :

/etc/firestarter/user-pre

First thing to do is to make it writable (it’s a read-only file) then paste these lines and save the file :

# Allow OpenVPN traffic
$IPT -A INPUT -i tun+ -j ACCEPT
$IPT -A OUTPUT -o tun+ -j ACCEPT

Restart Firestarter :

sudo /etc/init.d/firestarter restart

It should work now ! Just re-check your Online IP to see if it changed !

Many data center networks are configured as a single Layer 2 network, with the switches configured into a spanning tree to avoid routing loops (see the SEATTLE paper for some more background on how this works). However, in practice, simply finding a Layer 2 path to the appropriate destination host is not enough: data centers also include various “middleboxes” (e.g. firewalls, load balancers, and SSL offloaders) that intercept and sometimes modify Ethernet frames in transit. To ensure that traffic is routed to middleboxes as appropriate, network administrators typically modify Layer 2 path selection. This has a number of problems:

• Correctness: How can the administrator be assured that frames always traverse the appropriate sequence of middleboxes, even in the face of network churn and switch failures?
• Flexibility: Changing the middlebox routing policy should be easy to do.
• Efficiency: Frames should not be routed to middleboxes that aren’t interested in those frames.

To address these problems, “A Policy-Aware Switching Layer for Data Centers” proposes that Layer 2 routing policies be specified in a declarative language at a centralized administrative location. These policies are compiled into then compiled into a set of rules that are installed onto “policy switches” (pswitches). Pswitches make Layer 2 routing decisions by consulting a policy table, rather than the “destination MAC => switch port” mapping table used in traditional Layer 2 switches. New policies can be deployed by simply modifying the centralized configuration, which then disseminates them to the appropriate pswitches.

Policies take the form “At location X, send frames like Y to Z”, where Z is a sequence of middlebox types. Writing policies in terms of middlebox types, rather than talking about individual middlebox instances, makes it easier to reason about the correctness and how to handle failures without violating the policy. Rules take the form “For frames that arrive from hop X like Y, send to hop Z.”

To avoid sending frames to middleboxes that are not interested in them, middleboxes are removed from the physical network data path—instead, pswitches explicitly forward frames to middleboxes as required. The authors argue that because data center interconnects are relatively low latency, this doesn’t have a major performance impact.

Details

Making this idea work in practical networks requires addressing a lot of details. For example:

• To support load balancers, the right-hand side of a policy can be a list of middlebox types. The pswitch uses a hash partitioning scheme that is careful to send all the packets belonging to either direction of a flow to the same destination.
• To allow this work to be deployed without modifying the entire network, policy-based routing is implemented by encapsulating frames: to implement policy-based routing, a frame is encapsulated in another frame with a destination MAC of the next hop (middlebox or server) required by the policy. Frames are decapsulated before being delivered to middleboxes.

Discussion

I like this paper. There are only two obvious concerns I can see: the deployment difficulties in any attempt to redesign how switches operate, and the performance concerns of (1) rule table lookups rather than normal Layer 2 routing (2) the additional latency of traversing middleboxes that are off the network data path. Compared with a traditional software-based router, their software-based pswitch implementation achieves 82% throughput and adds an additional 16% latency. Middleboxes deployed with this architecture suffer a lot more overhead: 40% throughput and twice the latency. Its hard to say how the performance of a hardware-based pswitch implementation would compare with regular hardware-based routers.

The authors argue that the additional hop required to traverse a middlebox is acceptable, because data center networks are typically low latency. This seems backward to me: data center applications might actually want to take advantage of low latency links (e.g. see RAMCloud), and won’t like the network infrastructure adding additional latency overhead without a compelling reason.

“Internet Indirection Infrastructure” (i3) proposes a communication abstraction in which applications send packets to identifiers, rather than network addresses. Receivers register triggers that express their interest in packets sent to a particular identifier— the i3 infrastructure takes care of the routing. i3 is designed to be a general-purpose substrate, which can be used to build communication patterns including multicast, anycast, load balanced server selection, and host mobility.

Basic Model

To register interest in data, a receiver registers a trigger for the pair (id, addr) — this specifies that packets sent to identifier id should be routed to IP address addr. Multiple receivers for a single ID can be registered, in which case the packet is delivered to all matching trigger addresses. i3 generalizes this basic model in a few ways:

• Inexact matching. Identifiers are divided into two pieces: an “exact match prefix” of k bits, and a suffix that is used to do longest-prefix matches. That is, a trigger matches an identifier if the first k bits match exactly, and if no other trigger has a longer prefix match against the rest of the identifier.
• Identifier stacks. Rather than sending a packet to a single identifier, packets can instead be sent to a stack of identifiers. Similarly, triggers are generalized to mean “When a match for id is found, push a, b, … onto the stack.” i3 looks for a trigger that matches the first element of the stack; if no such trigger is found, the first element is popped from the stack. This continues until the stack is empty or a matching trigger is found; if a match is found, the trigger’s identifier stack is pushed onto the packet’s stack, and routing continues anew. i3 assumes that this process will eventually result in matching a trigger against an identifier holding an IP address. When that occurs, the packet’s data and the rest of the identifier stack is sent to the address.
• Private triggers. This is not an i3-level concept, but a design pattern that i3-using applications often follow. A “public” trigger is a trigger on a well-known identifier, and is used to initiate a session with a server; “private” triggers are used to communicate between pairs of end hosts. A pair of private trigger identifiers might be exchanged via a service’s public trigger identifier, and then subsequent communication will proceed via the private triggers.

Implementation

i3 is implemented on top of a distributed hash table (DHT); the authors use the Chord DHT in the paper. The DHT provides a service to find the node associated with a key; for the purposes of i3, this allows a packet sender to find the node that holds the triggers for the first identifier in the packet’s identifier stack (the DHT lookup is only done on the “exact match prefix” of the identifier). The target i3 node then finds the matching trigger, if any, by doing a longest-prefix match against trigger identifiers. Once a match is found, the packet is routed to the receiver address or addresses via IP, or another DHT lookup occurs (if the trigger contains an ID stack, not an address).

Senders cache the IP address of the i3 node responsible for each identifier. Hence, in the common case, routing an i3 packet requires two physical network traversals: one to get from the sender to the i3 node, and then another from the i3 node to the receiver.

Example Usage

i3 provides direct support for simple multicast; anycast is supported using inexact identifier matching, and appropriate choices for the inexact suffix of the identifier. Host mobility can be supported by simply updating a receiver’s trigger. Multicast trees can be implemented by constructing routing trees in i3, using the identifier stack feature (triggers that “invoke” triggers can essentially be used to construct an arbitrary graph, and to do recursive queries over graphs).

Performance

In the paper’s experiments, the latency to route the first packet to an identifier is about 4 times that of raw IP routing, because a Chord lookup must be done (after applying some standard Chord tricks to try to pick the “closest” Chord node among the alternatives as the ring is traversed). To reduce the latency required to route subsequent packets, i3 employs two techniques:

• Caching the address of the i3 node that owns a given identifier, as discussed above.
• A receiver generates k random trigger identifiers, and then chooses the identifier that it can reach via IP with the lowest latency.

By having each receiver generate 15-30 random triggers with this technique, the authors are able to reduce the i3 routing latency for subsequent packets send to an identifier to between 2 and 1.5 times more than raw IP.

Discussion

Overall, I liked this paper: it is an elegant idea that is explained well. A cynical view of this paper is that it isn’t all that innovative or “deep”: it is just a thin logic layer on top of a DHT. i3 is basically a generalization of the name-to-value lookup service provided by the DHT.

Both performance and security are serious issues with this design, and the paper didn’t really convince me that their approach addresses these problems.

I would have liked to see a performance comparison between IP-level multicast and i3.

It would be interesting to compare i3 with group communication systems (GCS) that provide totally-ordered broadcast messages.

In this installment, we’ll continue our look at OSPF (Open Shortest Path First). As we’ve seen, each router originates a Link State Advertisement (LSA), which is flooded throughout the internetwork. The LSA contains prefix and metric information for each link to which that router is directly connected. Each router maintains a Link State Database (LSDB) which contains copies of all LSAs the router has learned. Thus, the LSDB represents the detailed topology of the internetwork. Using Dijkstra’s SPF algorithm, each router independently uses its copy of the LSDB to develop its routing table.

So that all routers know which router originated which LSA, each LSA is uniquely identified by the originating router’s OSPF router ID. Like an IP address, an OSPF router ID is a 32-bit binary value that is commonly represented in dotted-decimal format. An OSPF router ID is assigned or selected as follows:

• If a “router-id” command appears under the OSPF process, that’s it.
• If not, it’s the highest IP address amongst the active loopback interfaces.
• If there are no active loopbacks, it’s the highest IP address amongst the active physical interfaces.

By active we mean not Administratively Down. In other words, a physical interface that’s Up/Down or Down/Down is still a candidate for OSPF router ID.

Note that although an OSPF router ID looks like an IP address, and may have been derived from an IP address, it is not an IP address. Instead, the router ID is used to uniquely identify the originator of a particular LSA within the LSDBs.

Key point: If you’re setting the OSPF router IDs manually using either router-id commands or loopbacks, they had better be unique! If not, corruption of the LSDBs and of the resulting routing tables can occur.

Two OSPF neighbors-to-be begin in the Down state. Once one of the potential neighbors has sent a hello, the neighbors move to Init state. To go further, the routers must agree on the following items with regard to the link which connects them:

• The subnet of the link
• The OSPF Hello and Dead intervals for the link
• The OSPF area within which the link resides
• Whether or not that area is an OSPF “stub” area
• Authentication type and keystring (if configured)

Assuming that the conditions are met, the neighbors proceed to Two-Way, which means that the neighbor relationship has been confirmed.

In the case of a point-to-point link (such as a serial link running HDLC or PPP), once the routers are Two-Way, they immediately proceed through Exstart, Exchange, and Loading, to Full state. Once they’ve reached Full state, their LSDBs are synchronized.

Next time, we’ll see how we handle LSDB synchronization on multi-access media, such as Ethernet LANs and Frame Relay WANs.

Author: Al Friebe