Jump to content
Search In
  • More options...
Find results that contain...
Find results in...


  • Content Count

  • Joined

  • Last visited


This user doesn't have any awards


About BSpendlove

  • Title
  • Birthday 1996-07-13

Contact Methods

  • Discord

Profile Information

  • Gender
  • Location
  • Interests
    Piano, Composition, Orchestration, Technology and Networking
  • Biography
    I love piano, networking and cats.
  • Occupation
    Network Consultant


  • CPU
    Intel i7-6700K @ 4.5GHz
  • Motherboard
    MSI Z170 Gaming M5
  • RAM
    2x8GB Kingston HyperX Savage DDR4 @ 3000Mhz
  • GPU
    2 x MSI GTX 1080ti Gaming X
  • Case
    ThermalTake X71
  • Storage
    2TB HDD and 250GB Samsung 850 SSD
  • PSU
    Corsair RM1000i
  • Display(s)
    LG 34UM88 - 3440x1440 IPS Superwide
  • Cooling
    Corsair H115i AIO
  • Operating System
    Windows 10 Pro
  • PCPartPicker URL

Recent Profile Visitors

3,157 profile views
  1. Now now ladies, we all know my router is bigger than both of yours. I don't see anything wrong with the above comments, sure 99% of the ltt community won't understand things like BGP or how something like NAT work, I think you both are having a good discussion but then it got a bit heated. But let's be serious here, by reading the Ops initial post, he probably doesn't need anything more than just NAT just for the purpose of the post. But you've listed many scenarios which are good
  2. Yeah because the UK only do that....
  3. You won't need access to the upstream device. You'd simply create a destination NAT rule, if pfSense sees traffic going to c.c.c.c then translate to nas ip address. This method is still considered as hairpinning or Nat loopback, depending on the vendor or whatever you want to call it Create a Nat rule and set the interface to your inside/lan interface, fill out source and destination networks and then use the redirect target ip for the NAS internal ip address.
  4. Yeah if everything is working, I wouldnt worry too much. Cns you specifically see that is 100% is a member of the stack within the management/cli?
  5. The stack cables are fine with a single cable but you reduce half of the backplane bandwidth for the stack. Similar with meraki and cisco, you typically would have something like 160Gbps of bandwidth on the stacking backplane, using a single cable will reduce it to 80Gbps. Not entirely sure on the throughput for the stack in those switches. (stacking throughput that is) I'll take cisco because I haven't worked with dell stacks but typically a cisco stack would auto provision itself, I think it's the same with these switches. Have you stacked them before? If not then check some basic things such as have you cabled up the stacking correctly? Cisco stacks port 2 to port 1, from top switch to the second member and carry on... Are the switches running the same firmware? Did you connect the stack cable prior to boot up the 2nd switch? If they are not the same firmware, dell has an auto firmware synchronisation for this that should initiate straight away when adding members into a stack. The 3000 series you need to cable bottom port of the first switch to top port on the next switch, did you do that? A reference for the 2000 and 3000 series https://www.dell.com/support/article/uk/en/ukdhs1/how10356/dell-emc-networking-how-to-stack-n2000-or-n3000-switches?lang=en
  6. Remember my friend, ip helpers with cisco (and equivalent for other vendors) are mainly for specific use cases. They won't forward all broadcast messages between subnets with that command alone, obviously the common ones being dhcp discovery, tftp, netbios etc.. and a few others but if you generated just a plain broadcast message the device will not forward it with the ip helper-address command. Just to clear up as well for others (I'm certain you should know this so it isn't aimed at you Juan) but the ip helper-address command is typically referencing an ip address with the command in Cisco eg. ip helper-address The broadcast is in effect, now a unicast. Where ever the broadcast was received on (eg an interface or vlan svi), then the source IP address of that interface is populated in the source address of the IPv4 header, and the address within that command will populate the ipv4 headers destination address, making it a unicast. It is no longer a broadcast.
  7. If you've ever used Cisco Prime Infrastructure's CLI Templating, you'll find that Cisco DNA's (Digital Network Architecture) CLI templating is an enhanced version found within Cisco Prime. Of course, there are many other features within DNA but this is just a quick example while I have 15 minutes of free time to demonstrate CLI templating and how it can be used to effectively deploy unified templates to a Cisco infrastructure instead of using other methods such as: Python + CLI scraping, Ansible, or Python with a combination of Git for version control. The concept of a CLI template is very straight forward although you need some consideration before deploying this on a global scale. Some considerations are: CLI Template versions for specific IOS (is the command supported in all IOS versions across the whole network?) CLI Template versions for specific models (Are you dealing with 9300s, 3850s? 3750Xs? even plain 3550s and 3750s?, are the models even supported with Cisco DNA? Find the supported devices here) Are you designing a generic template that can be used across all locations in the network or only a selected area? If you are designing generic templates, have you considered to create templates based on HQ Core vs Branch Access vs Warehouse Wireless? The very basics of CLI templating can allow you to just design a template with specific variables that a network engineer or level 1/1st line tech could use to deploy an access switch. You can ensure a unified configuration is applied to all remote devices upon first deployment but what stops those monkey techs logging onto a switch and changing configuration manually? It isn't smart to block login access for users and demand any configuration to be performed via a central server (eg. the DNA appliance) because there comes a time where someone may need access to a device to troubleshoot or simply put a port in a different VLAN. You have the additional features that can be integrated into your network such as Cisco ISE and TACACS+ but let's get back to DNA CLI templates. Let's create a simple generic template to be applied to branch access switches. We need to be smart about the templating. Our branches have the same model switch, running the same IOS version but the difference is that Branch-C has another switch. We would probably want to configure an EtherChannel (no lacp/pagp, just static) between SW1 and SW2 (let's assume its 4 ports, g1/0/45-g1/0/48), so we don't want to include that configuration within our generic global template, but some global variables/commands we can deploy across all the switches would be: Service password-encryption Set hostname (per device which can be done via the template deployment) Set Timezone and summer-time Set VTP mode to transparent Set the domain name on the switch Configure 2 x Domain servers that are located at HQ Some generic commands won't require user input such as enabling services, but others such as hostname will need some kind of input from either the user, or if you plan on automating this deployment you can pull data from a database (eg. a CMDB that ties into your network monitoring solution). Let's dive into the DNA template: I've created a new project and then created a template called Generic - General Access Switch Within DNA CLI templates, you can define variables like such: $myVariable This then allows you to specific edit the variable from the input form that you will see when you deploy the template. The common variable would be a string but others include string > select, IP address, MAC address, checkboxes etc... If we take something a bit more complicated, you can see that instead of making the user input commands such as spanning-tree portfast on interfaces the engineer would like this feature enabled, we can provide the option if they would like it enabled for the range of ports he is considering to be access ports at the specific branch site. This isn't the best example because the engineer has to be competent to know why they would want to enable portfast and to ensure that if it's a recommended design (instead of configuring via global) then to ensure they configure this on every port. That is where templating can't help you. You need to ensure staff/engineers are competent in their job and will follow documentation if you have a well documented deployment for branch access switches. Anyway, carry on: Cisco DNA CLI Templating uses VTL language (velocity template language). Let's change this variables so that the engineer can only set portfast to True or False and run a simulation within Cisco DNA. The big improvement with DNA is that unlike prime, there is actually a syntax checker that confirms if the syntax is correct. Cisco Prime would fail to deploy a template and then tell you something is wrong, always a handy feature. Take a look at the test simulation of our CLI template: Now can this be done other than using Cisco DNA? CLI Templating can be done with Excel spreadsheets and Python for all I care. CLI Templating can be achieved via Ansible or even writing your own Python library with Netmiko + some templating format of choice such as XML, JSON or Jinja2. CLI Templating isn't new but that isn't what Cisco's DNA solution brings to the table. The problem that we face currently is that these templates are not compatible with other vendor configurations. This is a common problem and there isn't a single interface to allow us to interpret a configuration for different vendors, we need to individually create templates depending on the Vendor, version, model and even the device role. While Cisco DNA states some other vendors are supported such as Palo Alto (for DNA inventory), it is much easier to use Anisble for smaller environments that don't implement a lot of Cisco. Cisco's DNA licenses are required when purchasing the new line of CAT9Ks (9200,9300,9400 etc...) but doesn't mean you can start running DNA centre. The DNA appliance is required along with a device license so be careful when trying to make the decision to run DNA. It isn't cheap nor something you should deploy in a weeks time.
  8. Here is a brief overview blog I created on MPLS L2VPNs (specifically Cisco's implementation of VPWS aka AToM, Any Transport over MPLS)



  9. Good luck running that on windows. Network tools from cli is no way or form obsolete, take a look at command line only Linux distros... Tcpdump, nmap, load more tools you'd run in cli.
  10. As I mentioned previously, it's rare and typically don't generate enough light to cause damage but it can in a 0.025% chance. It's happened to me with OM3/4 twice.
  11. I've had 2 clients do this and it broke the sfp. So it does happen. Edit:probably rarely, but it does happen.
  12. But yes, the TX part of the SFP will generate the actual laser and the receiving side would just kind of act passively and terminate that laser, so you're right in swapping them over.
  13. If what you've mentioned as the laser collides on the same fibre, you can potentially cause issues with the SFP if you accidentally do this. You've probably damaged the SFP and now it doesn't work more than x distance
  14. It would be nothing related to GNS3, you'd have to implement what sites like whatsmyip.com do. When you create a web server within GNS3, your client acts exactly how what would happen going to eg. whatsmyip.com. You'd establish a TCP connection, http get, web server responds but will update it's webpage with the external IP address that you used to query the http data. You might be looking for something more like: https://www.virendrachandak.com/techtalk/getting-real-client-ip-address-in-php-2/ where you implement the ability for the web server to retrieve the clients IP address, this should work is GNS3 as expected.
  15. BSpendlove

    DNs query

    You want to look more into the DNS process with how dns namespace and delegation works but take an easier example with something like a.mywebsite.com Consider the scenario where your DNS server doesn't cache any dns queries and that your upstream DNS eg. Let's make it easier and say a windows 2019 server running DNS called DNS01 Firstly, as you mentioned the user tries to query for A.MYWEBSITE1.COM, it tries to query its own dns server (eg. A router we setup to forward dns queries we can't resolve onto DNS01) DNS01 receives this request but doesn't have a clue where even mywebsite.com is. Let's back up a tiny bit, the com is typically referred to as a 'top-level' domain and isn't managed by typical DNS providers. Remember that our DNS needs to propagate to the top level root DNS servers around the world blah blah blah. DNS is not designed to work as a kind of daisy chain where you query the root server, that server queries eg. A com server, which then manages to find an entry for mywebsite and then return it to you. That is not how DNS is designed and it doesn't work this way. Dns is quick, lightweight and to this day, has no problem making multiple queries to a few different servers to finally get a specific reply to send back to the original client. From a DNS architecture point of view, I can't comment much but I could see that allowing the one single server to query eg. A root server, then a top level com server would be much easier to implement on an operating system level and from a sockets point of view within how the network stack is implemented in the operating system. When you take an example of a deeper subdomain like: a.b.c.mywebsite.com It doesn't work how you mentioned in regards to dns queries and what I mentioned above as a rough example. Normally a.b.c would exist as an A record and you wouldn't need to make like 4 queries. From a DNS server that needs to contact a top level server would just query the com server and be done with a single query.