Recent Posts

Pages: [1] 2 3 ... 10
After wrestling with YDK (YANG development kit) installation for more time than I'd like to admit, I automated the thing in Ansible so I can reliably instantiate it at will.

0.7.1 has a convoluted install, hacks involved, and the documentation is.... eh.... (lets just say that parts contradict other parts, and parts that don't work aren't removed/caveated).

YDK is this

Voice, Video, and Telepresence / QOS expedite causing access issue with STP
« Last post by zackburf on April 24, 2018, 02:42:05 PM »
I have Adtran switches across my network. What we have found an issue with access when STP blocks a port in a specific instance.  The instance we found is when there is a loop in an unmanaged switch that is connected to the Adtran.(I know unmanaged switches are the devil and budget wise we are working to get rid of them.)  What happens is a user creates a loop in their office with the unmanaged switch and then the Adtran kills that link to the unmanaged switch. This is great because it stops the loop from hurting the network.  All the computers on the Adtran retain internet access and voip phones work fine.

Here is the weird part, when it blocks that port we lose all remote access to the switch. I have confirmed STP is blocking that port by consoling into the switch.  This only happens we are using QOS to expedite voip traffic. When we turn qos off the STP still blocks the port and we keep remote access.

I have tested this in a lab enviroment with not other traffic besides my computer and the loop in an unmanaged switch and the same thing happens. I have found when I weight the qos VOIP queue to 255 instead of expedited I keep access as well.

My question is this.  With VOIP do I need to keep the voip queue at expedited traffic or can I just leave at 255.(The other three queues are set to 25)

Second question is does anyone know why expediting COS vlaue 5 traffic in queue 4 is stopping remote access and pings during the loop.

Security / CounterACT Custom Conditions
« Last post by deanwebb on April 24, 2018, 02:18:02 PM »

Very cool, shows a great way to build out a tool within the product.
VRF-Lite worked a charm.  Easy to set up too.  I didn't think it was working at first, but after re-coordinating with the system admin we discovered he had some things set up wrong on his end.  But it's working and we didn't blow anything up in the process.  I'll take that small success!
The eventual goal is Active/Active datacenters. But we're not there yet! 
This is why we VXLAN/OTV :)

Doesn't help your current situation, but it is what you should be striving for. The goal for DR is to have be as automated as humanly possible. By this I mean, DNS records the same/different but already configured, IP addresses the same/different but already configured, external IPs the same/different but already configured, etc. The only difference should be physical location & host.

If you can't do this I recommend something like SRM. Then having a duplicate network in another site with different L3 IPs and script SRM on failover to change the host IPs. For example if HQ server vlan is, in SRM you can have all the VMs change their networks to X.1.X.X/24 to then automatically change. You then have DNS records already in place (less preferred obviously) to support those services. The same goes for external IPs. NATs already in place. This makes your DR automatic, and require ZERO manual changes.

Management Tools / Re: Free Fundamentals 1 Splunk Training & cert
« Last post by deanwebb on April 23, 2018, 09:57:25 AM »
Cool, thanks!
VRF-lite is your answer.

Your VLANs need to be different numbers but if you create everything in a VRF you can even dupe IP addresses. Just don't accidentally 'cross the streams'....

OR you could do a really nasty hack with ACLs on all the isolated VLANs but then you have to use different IP addresses:

(inbound on SVI)
- allow ip any <DR bubble summary>
- deny ip any any

Most of the time the fact that its DR means that people really love the idea of having the same IPs hence VRFs

Looks like VRF-lite is the way to go.  Now to do some googling and learning...
humm, when off on a tangent, there thinking same IP's on both networks don't know why,

even easier,  hang a new switch off the 6500'  on it's own vlan,   create the security ACL to block in/out, static routes to the new environment
and connect everything up to the new switch. did this at another gig, mock up of a network build we rolled out to WA state.
fairly easy, pc with 2 nics, that'll work,  1 nic connected to prod, and 1 nic connected to DR.  Remote into the PC as a gateway to the other network, then into other devices,  PITA and slow.
you can build a small unique transit network on the inside to get around the duplicate IP address issue.

Beware that your temporary solution to run some test will turn into a production network

Here is why,  you won't have access to all the tools and resources you'll need,
someone will need NTP, to make time accurate,
someone will need internet to download some patch directly from the vendor
and that download can't be done via IP, so they'll need DNS.
management won't want to get another license for some expensive proprietary software, so that'll need to touch production
someone will want to touch the production AD for some reason, maybe authentication
then some manager will need to see what going on, so you'll need to setup some sort of logging and reporting to production
on and on and on.

Believe me, at my last gig, we had a pre-prod environment for staging prior to deploying into production, we did have a firewall and NAT, and RDP and all that, it was a PITA.
it wasn't like production, although said to be, it was a mish-mosh of crappy spare parts we has lying around, and piece hammered together with paper clips and bubblegum.
it was all overhead, didn't make the company any money, so there was no investment. That and nobody wanted to go through the process to update the pre-prod environment when changes were made to prod, so every time someone needed to setup in preprod it was a scratch and think event to figure out what changed in prod over the past weeks or months to make this damn thing work in pre-prod.

Pages: [1] 2 3 ... 10