Tutorials for 2017

NETWizz

Well-Known Member
Reaction score
1,925
Good Morning:

I am thinking of writing some more network tutorials for the community. I think I wrote only three (3) based on traffic shaping and prioritization, which is especially useful for VoIP; then another on IPv6; and one on HSRP to have multiple redundant routers. What would you folks like to see? I am trying to think of things that will actually be useful for most tech folks. My experience as a network engineer is just plain different than that of most computer technicians, so I have a unique perspective on networking that is "different" than that of computer technicians. For example, much of what I do is pretty much useless to you and to small organizations for example Policy-Based Routing and VRF Routing probably make no sense for a small organization.

I still want to talk about Link Aggregation and VLANS as promised earlier this year.

That said, I would like to do something you folks can use to really set yourself apart from the competition. What do you folks think of perhaps I write a tutorial on how to do secure, Virtual WAN links over the Internet?

i.e. Say you setup one site as 192.168.1.x and another 192.168.2.x and another 192.168.3.x, etc. I could make a quick tutorial on how to easily make these sites work just as they would independently to the Internet and LAN network only between each other also setup a virtual WAN over GRE tunnels secured with IPSec.

The benefit would be your customer with more than one location could reek ALL the benefits as a corporate WAN would without paying for Metro-E or MPLS. Quite simply, browsing the Internet from say 192.168.1.23 would hit router 192.168.1.1 and go directly to the Internet just as it does now (split-tunnel), BUT if they did something like open a spreadsheet at a remote site hosted by a server on the 192.168.2.x network it would simply and transparently work (provided the file-sharing was setup properly). They could print to a network printer at another location just as if it were in the next room over, authenticate against an Active Directory Domain Controller in another City, use central inventory software, share web-based software i.e. PCRT etc.without having to install a different instance at every site, etc...

What would you folks like to see?
 
That sounds amazingly good!

Good enough that I would be happy to contribute to some kind of fund for it. Or if you don't want that just list your favourite charity and where I can make a donation.
 
What situations would you recommend a GRE tunnel instead of a VPN?

Also, I would be interested in the best ways to link in cloud resources (Azure, AWS) in to an organisation's network.
 
For my own selfish reasons I would like to know what I should do if I have a peplink multiwan router that has crappy QoS and I want to setup superior QoS but using the same router. I suppose theres managed switches with QoS features arent there?
 
That sounds amazingly good!

Good enough that I would be happy to contribute to some kind of fund for it. Or if you don't want that just list your favourite charity and where I can make a donation.

Actually, I would rather you keep your money. If you want to make a donation, pick a good, local charity in Ireland.
 
For my own selfish reasons I would like to know what I should do if I have a peplink multiwan router that has crappy QoS and I want to setup superior QoS but using the same router. I suppose theres managed switches with QoS features aren't there?

Yes, the Mulit-Layer Cisco switches come to mind, but generally you need only do QoS on outgoing traffic such that it guarantees Voice will get through or limits the amount of offensive traffic that gets through. Hence, you really need only do it on one (1) router interface that said, you can of course use a Layer-3 switch as your router. This is predominantly better to do from a Data Center with a high-speed link when there are other, slower WAN sites. Basically, you shape the outgoing to not crush the receiving site. I have not worked with Peplink equipment, so I would have to read the documentation. If you send me the use case and the documentation, I will help you interpolate it from Cisco to Peplink.

Here is what I do for a site with VoIP equipment that sets a DSCP flag of EF on the packets (Layer-3) AND the provider requests a COS flag be set of "5" for the priority bits (Layer-2):

Code:
class-map match-any VOICE
match ip dscp ef
!
policy-map VOIPMAP
class VOICE
  priority
  set cos 5
!
policy-map 10M_SHAPE
class class-default
  shape average 10000000
service-policy VOIPMAP
!
interface SomeLink 0/0
  description The AVPN WAN Link
  bandwidth 10000
  service-policy output 10M_SHAPE
!

What this does is set the metrics for a 10M WAN circuit, such that the router/switch knows to base the metrics off of 10000 (proper reporting but otherwise the bandwidth 10000 does nothing), then it applies a nested policy. The 10M_SHAPE policy shapes ALL outgoing traffic to 10M, which creates a laminar flow preventing the TCP Sliding-Windows problem, and then that 10M_SHAPE policy applies a VOIPMAP policy which matches Layer-3 Packets with the DSCP flag set to EF and to those packets changes the queuing mechanism to Priority, which comes first and is lower latency than WFBQ or FIFO, and it sets the priority bits, which the provider (i.e. in this case AT&T) will recognize on the other side.

Some of these things need to be tweaked to adjust for your actual bandwidth, how you are going to match your VoIP traffic (it may be your equipment does not set DSCP flags and you use an ACL instead), and the provider might request a different prioritization.

What I am saying is that everything depends upon the use case, but this should be able to be translated into Peplink. I need your particular use-case though before I can tell you what I would do in your situation.
 
What situations would you recommend a GRE tunnel instead of a VPN?

Also, I would be interested in the best ways to link in cloud resources (Azure, AWS) in to an organisation's network.

You might want to write the portion on using Azure, but it should be no different.

A VPN is generally a tunnel one uses to connect a computer to a specific LAN network subnet. It is not generally used to create a WAN backbone whereby connecting a bunch of LAN network segments together into a unified WAN.


GRE is just Generic Routing Encapsulation. In and of itself it is NOT secure alone, but what it does is give you an easy to use, solid infrastructure to build upon. This is essentially what it is designed to do... Fast-forward a few decades and nobody in their right mind would use it without encryption outside a lab environment, BUT it is still the foundation in that IPSec Alone merely matches Access-Control-Lists and is not itself that useful for making a Virtual WAN.

What GRE ultimately does in practice is make a logical interface (i.e. Tunnel0) on a two pieces of networking equipment (i.e. routers) and for all intents and purposes, those two (2) interfaces are connected together by a virtual Ethernet cable that directly connects those two interfaces... even though they may be across the City, State, or on a different Continent! Then if you set an IP address on both of those interfaces like you would WAN interfaces (within the same subnet of course) they are now Layer-3, route-able interfaces with both routers now each having an interface sitting on a shared subnet! Once you do that, it will, of course show up as a directly-connected Route:

C 192.168.1.0/30 is directly connected, Tunnel0

In this case, you could for example ping across this virtual WAN interface. In this example I used 192.168.1.0/30 which has two (2) usable IPs 192.168.1.1 on one router and 192.168.1.2 on the other (mask is 255.255.255.252 for /30).

It would ping just as if both routers were sitting in the same room with a network cable connected on two interfaces (only with more latency because of the Internet):
Code:
Router#ping 192.168.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/0/0 ms

Router#


It is at that point you use the Tunnel as if it were a WAN link. You could tunnel everything over it (i.e. a default route) except the GRE Tunnel itself needs a route to the other end (in this case 1.2.3.4):

ip route 0.0.0.0 0.0.0.0 Tunnel0
ip route 1.2.3.4 255.255.255.255 GigabitEthernet0/1


Or you could do a split-tunnel and send back only the private network(s)... Everything else to the Internet. Here I will send back a summary-route for ALL the private networks:

ip route 10.0.0.0 255.0.0.0 Tunnel0
ip route 172.16.0.0 255.240.0.0 Tunnel0
ip route 192.168.0.0 255.255.0.0 Tunnel0
ip route 0.0.0.0 0.0.0.0 GigabitEthernet0/1

You could do policy based routing routing, VRF routing, pretty much anything you wanted. You could mix and match these with existing MPLS networks, really it is endless.

What my tutorial will ultimately do is show how to setup a GRE tunnel... How to do the routing, etc.

Then it talk about how to secure the tunnel with encryption, so it goes from a brilliant idea and pipe dream to a usable solution.
 
Last edited:
A VPN is generally a tunnel one uses to connect a computer to a specific LAN network subnet. It is not generally used to create a WAN backbone whereby connecting a bunch of LAN network segments together into a unified WAN.

I would say site-to-site VPNs are quite common for SMB. However a GRE tunnel does sounds like it would be better when you have small branch offices without their own resources. With a GRE, a DHCP relay would not be necessary right?
 
I would say site-to-site VPNs are quite common for SMB. However a GRE tunnel does sounds like it would be better when you have small branch offices without their own resources. With a GRE, a DHCP relay would not be necessary right?

If the DHCP server is not on the same local, Layer-2 network segment then YES just like in a standard WAN topology you need to tell the router where to forward the DHCP requests. You would specify this on whatever Interface the computers are communicating with as the Default Gateway. If this is a Multi-Layer switch, that is most likely a logical VLAN interface. If this is a router, then it is the LAN facing interface.

Regardless, you would put it on the LAN-facing side NOT the Tunnel interface no different than if it were a standard WAN. If those DHCP servers happen to be on the other side of the tunnel, it will work just perfectly fine.

Something like

ip helper-address 172.16.1.2
ip helper-address 172.16.1.3
 
Well I'm certainly looking forward to your tutorials. My goal for 2017 is to buckle down, study and get CCNA.

Do you think GRE tunnels are faster than site-to-site VPN?
 
Well I'm certainly looking forward to your tutorials. My goal for 2017 is to buckle down, study and get CCNA.

Do you think GRE tunnels are faster than site-to-site VPN?

Not faster, merely different. I know that is a horrible answer, but typically VPN is a client to network where GRE is network to network. Getting the CCNA won't be bad at all... It is a straight-forward exam.
 
APs and WIFI solutions are my interest in networking, if you will.

They are the bane of my existence, lol... that and printers.

What would you like a tutorial on doing Enterprise RADUS authentication using Active Directory Credentials?

From a network standpoint what to know is that for roaming to work you need to use the same subnet and same SSID. Rarely does L3 Mobility tunnels between APs work reliably.

What you want is a bunch of instant APs (i.e. one is elected controller) spread around. If you have multiple floors you are better off trunking a VLAN through such that ALL the APs are on the same subnet otherwise if a signal is stronger to another floor, your computer will roam associating to a different AP. The problem will be the IP of your computer does not change to match the new subnet.

Additionally, for reliability purposes, you need to keep the AP management traffic separate from the actual data traffic. To do this, you take an SSID and statically configure it to a tagged VLAN and the switchport the AP connects to needs a dual personality port such that untatagged traffic goes into a management VLAN and the tagged (802.1q) traffic goes into your wireless data traffic VLAN.

^^^ These are the things you figure out with years of experience... but they don't matter until you are in a multi-VLAN building and have hundreds of users per AP and a LOT of APs. (it is not uncommon for us to have about 7,000 users connected to about 300 APs simultaneously). Before partitioning the management traffic and the data traffic into different VLANs when it became saturated APs would stop seeing the controller and reboot. Now it is rock solid.
 
Last edited:
Back
Top