|
Feel like i'm being hella dumb with this one but would like someone to double check me on some basic HSRP poo poo if possible before we commit to something bad. I've got 4 Nexus 9300s in 2 vPC domains in our new data centre - 2 fibre (our 'core' switches), 2 copper (extra 'core' poo poo that doesn't use fibre/management/whatever). The vPC peer links are connected via 100gig on both pairs. The copper switches are connected to the fibre ones on 2 vPCs over 20gig each. We're getting a managed (ugh) IPVPN MPLS from our service provider. They're providing us 2 ASRs with a single 10gig port each. We're also going to have 8 VRFs on our Nexus switches and the ISP routers. They're going to give us subinterfaces presented on a .1q trunk with HSRP on each subif. Originally my bosses wanted to buy another pair of 10gig switches to run the HSRP through, so ISP Router -> 10gig switches -> Nexus. I don't want to pay for anything so i said we could just make all the layer 2 vlans on the copper switch and connect it to that. Now i'm second guessing myself and thinking is that even going to be necessary? couldn't I just patch one ASR into a fibre switch and the other ASR into the other fibre switch and the HSRP information will be exchanged over the vPC peer link? All the SVIs and VLANs are going to be on there already in their relevant VRF Contexts. Theoretically it should work but I'm doubting myself and getting thrown off here because the Nexus fibre switches are going to be doing routing and that's making me think it might mess with the HSRP info. Typically i'd just throw a blank 2960 in the middle but that's not going to work here and I don't have any spare routers lying around that I can lab this on. uhhhhahhhhohahhh fucked around with this message at 20:31 on Dec 24, 2018 |
#
¿
Dec 24, 2018 20:05
|
|
|
|
| # ¿ May 14, 2024 13:41 |
|
|
BaseballPCHiker posted:I am definitely not a licensing hardware guy so please forgive my ignorance. Is the only difference between DNA Essentials and Advantage is that I can make a device a layer 3 switch? Both can do dynamic and static routing. There might be some features missing from Essentials for EIGRP for example but I couldn't tell you what they are. If you were doing full MPLS you'd need Advantage for certain though. We didn't like this DNA garbage and bought the perpetual NX-OS Essentials 'old style' license for our 9300 switches. I've set up VRF Lite on them with EIGRP and OSPF so I know it works. It took us way longer that it should have to get our heads around this DNA nonsense but the takeaway is, unless you have basically nothing and you're starting from scratch - I mean no Wireless and no ISE mainly - it's not worth being on the hook forever. If you've already got an ISE deployment with xxxx amount of base licenses and wireless controllers with licenses it's just not worth it. I suppose if you were doing a refresh you could consider it but even then you're going to be on the hook for a lot of revenue every 3 or 5 or 7 years because even if you stop paying the DNA Essentials for example, your switches keep Essentials features perpetually but you lose all the SDN access and you lose your wireless and ISE licenses. Your licensing costs will go through the roof and you still have to pay up front for the hardware as well. The backend appliance for their new management software for the Catalyst switches is like £20k on it's own.
|
|
#
¿
Jan 8, 2019 00:58
|
|
|
Woof Blitzer posted:Are optical transceiver modules plug n play? Yes, so long as you bought the right one for your fibre and that they're Cisco branded. You can use non-Cisco ones uses a hidden command but TAC won't help you if you have problems (even if they're unrelated, from what I've heard) If possible, look at Direct Attach Cables as well. They're less flexible because the 100gig ones, for example, have fixed length limits, but they're much cheaper than SFPs.
|
|
#
¿
Feb 17, 2019 01:49
|
|
|
BaseballPCHiker posted:I've got a very annoying problem that will be resolved with a code upgrade and reboot soon but in the meantime messages are spamming my syslog like crazy. I had trouble doing my own discriminator using mnemonics, and had better luck with msg-body instead. I did this for blocking dot1x logs instead: 'logging discriminator AuthFail msg-body drops Authentication failed for client' Although I never tested this on logging to a syslog server, just on the buffer. Couldn't you also just set your syslog server to drop that message? You can also disable logging of neighbour changes and warnings under the eigrp process but you might lose useful information doing that uhhhhahhhhohahhh fucked around with this message at 00:53 on Mar 14, 2019 |
|
#
¿
Mar 13, 2019 13:56
|
|
|
Yeah I'm struggling to figure out where that screencap is from. If you're making a Flexconnect ssid it doesn't technically need an interface on the WLC, the management one can be set fine from what I remember. You set the native vlan on the switch port and under the Flexconnect tab on the AP for it's IP, then set the Flexconnect vlan for the ssids for the AP (or with a Flexconnect group). That VLAN needs to be on the switch the AP is on and have access to wherever your DHCP is of course
uhhhhahhhhohahhh fucked around with this message at 14:51 on Mar 23, 2019 |
|
#
¿
Mar 23, 2019 14:49
|
|
|
adorai posted:A little research led me to the command peer-gateway, which I entered on my 93180 pair under vpc domain 1. This appears to have solved my problem. It is a little wishy-washy as to whether this is best practice or just an unsupported crutch. I have that on all 3 of my vPC pairs. I think I also threw peer-switch on it for good luck as well.
|
|
#
¿
Mar 28, 2019 13:06
|
|
|
Having some weird packet loss/routing/layer 2 problems last week with my Nexus switches & managed MPLS ( ), I semi-fixed it and I think i might be overthinking things super hard here.Backstory: We've got a (brand new) primary DC and a (old primary) secondary DR DC, connected via a trunk port ( ) with only a server VLAN allowed across that trunk at the moment. I explained it wasn't the best idea, but my suggestions of using VXLAN or just having a separate server subnet at each DC and using DNS for DR, instead of static IPs, for our 100ish and growing VMs was shot down by my managers. Things are extra messy because we're still migrating from our old unmanaged EVPN on a different EIGRP process to this new IPVPN, and the EVPN core is at our secondary DC, along with still moving poo poo from one DC to another, so there's constant changes. We control the routing at our DCs using our Nexus switches, we have an EIGRP process for each VRF that the ISP redistributes into their BGP MPLS. the other ~70 non-DC sites just have the managed router and our switches. The server subnet is advertised out at the primary DC at the moment, but can be advertised out of both if we want - the idea is that, in the event of a disaster, we move the SVI for the VMs (25.1/24) from the primary nexus to the secondary, add it to the EIGRP and then bring all the servers up there and we don't have to involve the ISP and wait 4 hours for them to change the routing.We have a SIM APN that we use for remote access, and they were dropping a ton of packets to the servers and anything on different ranges that's at the primary DC, and the traceroutes had lots of drops and unresponsive hops that shouldn't have been there - traces to devices at the secondary DC were fine. They come in from a leased line to the SP's router, then an interconnect router (i didn't set this up), that has a GOLR to the secondary fibre nexus which then would've been layer2 to the servers at the primary DC. The nexus at the primary DC has a static for the SIM subnet (30.0.0/20) via the secondary nexus fibre (25.4/24), which has a route for that subnet in it's routing table from the old EVPN EIGRP process via the interconnect router (25.254/24). Trying to figure out what i'm missing here/why i'm very dumb, because the routing for this should work fine? despite being inefficient because there's an extra 'hop' in the middle. The fix for it was changing the static route for the mobile device subnet on the primary nexus to point directly at the APN interconnect router interface. an additional, similar problem: dropping a ton of packets from a non-dc site (12.0/23) to the secondary nexus copper switch management IP, 27.2/24. Trying to keep it as simple as possible, it only has the management SVI and only layer2 vlans. All the SVIs for the other subnets there exist on the fibre switch. it only has a GOLR under this VRF to the fibre switch - 27.1/24 - and that knows the route back to the non-dc site from the IPVPN EIGRP via the MPLS router (27.254/24). Again, to me, this should work fine? the fix to stop it dropping packets was to set a static for the non-dc subnet via the MPLS router's IP. doesn't make much sense why it worked though, since the GOLR sends everything to the fibre switch, which then knows the route back to the subnet. This poo poo is making me feel hella dumb, and it doesn't help the weirdness started happening at the end of a 14 hour day because we were doing some other work. made a quick & bad drawing to show how this specific stuff is connected, if it makes my rambling easier to understand: Data centre link is 10gig p2p. 
uhhhhahhhhohahhh fucked around with this message at 21:41 on May 4, 2019 |
|
#
¿
May 4, 2019 20:11
|
|
|
Opps, forgotten to mention. The link between data centres is a 10gig point to point. I wouldn't have done this either, I mentioned having 2 different server subnets and using DNS but they shot me down
|
|
#
¿
May 4, 2019 21:40
|
|
|
Thanks Ants posted:Are you doing anything to filter broadcast or proxy MAC discovery between the two sites? It's just a trunk port with a single allowed VLAN statement. I still haven't figured out why the static routes for intermediary hops were causing problems. I removed the route I'd done before the weekend for the management of the copper switch at the secondary DC, it's gone back to use the EIGRP route like before and it now it works fine, no dropped packets  who knows.I half got my way anyway, they've said once we've moved over everything on that server vlan from the secondary to the primary, I can make 10gig point to point layer3. They still won't let me do VXLAN though, too bad. There won't be any automatic failover if our primary dc gets exploded, and I'll have to move the default gateway IP for the severs over manually, but all the VMs will need to be brought up manually as well anyway.
|
|
#
¿
May 8, 2019 11:10
|
|
|
My boss is too cowardly to let me use non-Cisco transceivers. We've probably spent £20-30k in the last year on 10gig and 1gig SFPs. I've got about 25 1gig transceivers that our ISP sends out with their NTUs that they never bother to collect sitting in a drawer.
|
|
#
¿
Aug 12, 2019 18:01
|
|
|
Tetramin posted:Hmm maybe I’ll try to replace the syslog server I had our system guys build with a Linux box then. They built me a windows box but if it’s free I can probably change that. I have no attachment to OS for this. We're testing out Graylog at the moment, seems pretty good.
|
|
#
¿
Aug 14, 2019 09:59
|
|
|
MF_James posted:So, I'm mildly perplexed by this, the situation is that I have an ASA5515 pair that is logging to a syslog server, I have moved the syslog server to a new machine (from a win7 desktop to a server 2019 VM), since doing that I'm no longer getting netflow logs. Did you add the new IP in both places? If you're doing it through ASDM, you do it on the device management page and on the Service Policy page.
|
|
#
¿
Sep 13, 2019 18:19
|
|
|
MF_James posted:Both places? We don't have netflow explicitly configured, it (should) be sent because logging level is set to debugging and debug-trace is on; if that's what you mean. Doing this all through the CLi, I don't really use ASDM. I don't think that's technically netflow, just the standard ASA log about connections being created, ended or denied. This is the guide I used to get started with it: https://community.cisco.com/t5/security-documents/configuring-netflow-on-asa-with-asdm/ta-p/3119466
|
|
#
¿
Sep 13, 2019 19:42
|
|
|
On the netflow summary page, using the flow navigator on the left, you can change to Detailed in the first section. Then choose the endpoint that your screenshot is from and you can filter by that protocol, and the time range it was in. This should give you a page that has Endpoints that generated the traffic and Conversations between devices if there was a source and destination
|
|
#
¿
Oct 2, 2019 12:46
|
|
|
Cool ASA poo poo: upgraded a 5525X to 9.8(2)35 last week and now the ASDM logs are spammed 30 times a second with ICMP logs that are supposedly coming from the next hop for the management interface - a Nexus 9k - which definitely isn't doing any tracking or icmps to this device.
|
|
#
¿
Jan 6, 2020 11:14
|
|
|
Prescription Combs posted:That's pretty old code, might wanna consider something in the 9.12(2) interim train I'd love to but they won't pay for a support contract here so I've got to make do with what I've got. I've got an ASA cluster on the same version in a different DC that isn't doing the same thing. Unrelated, but has anyone used/deployed Catena on Nexus switches?
|
|
#
¿
Jan 7, 2020 11:05
|
|
|
Prescription Combs posted:
Both the same as far as I can see. The workaround would be to disable those syslog messages but then I'd lose ICMP messages for troubleshooting.
|
|
#
¿
Jan 10, 2020 11:15
|
|
|
I'm currently in the process of setting up a new HA pair of PA-3220s, going to be migrating from some Huawei NGFWs. I've used Cisco ASAs as well and the PA is so much easier to work with compared to both of them. The documentation is incredibly well written, has a bunch of examples and it's easily googleable when working out the quirks. Most of the basics carry across between all the firewalls but there's always some stuff they do differently, like no VRRP on the PAs. I fuckin hate having to do anything on the ASAs, cli and asdm both loving suck, and our ASA pair is in a cluster because they bought a gig internet and our model only has 650mbit throughput. Not done much on cli yet though so can't say how good it is. Expensive as poo poo though, cost us like £24k each for 3 years of licensing. The Huaweis were like £3k. uhhhhahhhhohahhh fucked around with this message at 14:08 on May 21, 2020 |
|
#
¿
May 21, 2020 14:05
|
|
|
The DHCP option never did anything for me. Have you done the DNS entries for CISCO-CAP whatever? Even with them we'd still get random ones that just didn't seem to want to join. Manually putting controller IPs from SSH or Console always seemed to sort it out, mine are all 2x00 series APs though.
|
|
#
¿
Jun 17, 2020 17:42
|
|
|
Time to start looking up phone numbers and emails for division/senior managers/CEOs on LinkedIn and start spamming them about the lovely service you're receiving.
|
|
#
¿
Jul 24, 2020 17:09
|
|
|
Thanks Ants posted:I understand people have QoS requirements or compliance issues but I cannot be arsed dealing with WAN stuff from ISPs any more, they always gently caress the routing up or you get a different configuration built depending on which tech builds the changes, with each change request just compounding the disaster of a state that the configurations are in. I don't care about any of the potential cost savings or the carrier diversity, for me the best thing about SD-WAN overlay using VPN tunnels is that I can see the config that's running and get it changed without five days notice. We moved from an unmanaged VPLS to a managed L3 MPLS and it's total dogshit. My managers tried to sell me on it because 'we wouldn't have to worry about routing' and that it would be someone else's problem (????) and it saved £10k out of a contract that's over a mil. I still have to worry about routing, it's still my problem because I'm expected to fix it, except now I can't fix it when there's a problem and were buried under layers of jank trying to make poo poo work because it turns out the ISP doesn't have dozens of network gods waiting to implement the perfect network for us. We'll be putting up some new DHCP servers soon and we'll have to pay like £300*50, one for each site to have its IP helper reconfigured, because they poo poo on my idea to have our own L3 switch or router at each site that we peered with the ISP router so we could at least be in control of things like that. When we were transitioning our backup DC to the new network and obviously, there was a problem with the VRFs. We got a call booked and an engineer and I asked him to check the config on their router, he was silent for a minute or two and then said, "sorry, i don't know what a VRF is." Felt super bad for him. What a bunch of pieces of poo poo booking that guy onto the call in the first place.
|
|
#
¿
Jul 27, 2020 17:02
|
|
|
Kirk Byers seems to be a good resource. Every time I try and get through his free beginners course some bullshit project comes up so I can't say if it's actually good or not. He's involved in lots of other stuff though, and the #networktocode Slack is semi-linked to him/netmiko/napalm/nornir/eNMS I think. His website: https://pynet.twb-tech.com/
|
|
#
¿
Aug 13, 2020 17:27
|
|
|
Kazinsal posted:I've got a couple dozen Cisco devices that I need to regularly back configs up for but can't change the configs on to have them automatically push their configuration anywhere. Does anyone know of a tool or expect scripts or something that I can just drop into a cron job that'll basically ssh in, show running-config, and copy the output to a file? If you can enable scp on them, you can automate pulling the running or startup config from them in any way you please
|
|
#
¿
Sep 23, 2020 22:14
|
|
|
I have to look after a cluster of 5525Xs and they're such loving garbage. It just inexplicably stops forwarding traffic if one specific firewall becomes the master, but it works fine when it's not. Also gently caress ASDM forever.
|
|
#
¿
Nov 8, 2020 20:47
|
|
|
Jedi425 posted:Check the syslog settings. Are you forwarding syslog to a TCP port? If the host is unreachable, the ASA stops forwarding. Could be you have some kind of issue reaching it from one and not the others? Syslog is UDP and it's done over the OOB management, so it's always reachable. We also only recently got a SIEM anyway and it was happening before. Kazinsal posted:I think the only reason I would use an ASA or a FirePower running ASA code over a more competent firewall is if I needed to handle a few tens of gigabits of L3/L4 traffic and needed to programmatically change non-persistent firewall rules in a dumb and quick manner via clogin or something like that. All the documentation for clustering on ASAs is filled with notes saying TAC don't support this configuration at all. My boss wanted it this way for zero reason, we gain nothing doing it this way over a HA pair because our internet connections are 1gig and we can't active/active them either. He knows that because he was on all the same phone calls as me with our ISP saying we couldn't do that, but acts surprised 1+ years later when it's ever mentioned they aren't active/active or I have to correct him on a phone call. Also, the audacity on you to assume we pay for TAC, or even software updates, on our edge firewall.
|
|
#
¿
Nov 8, 2020 23:58
|
|
|
I've got a turbojank setup but I can't do anything about the jank. Trying to make some OSPF <-> EIGRP redistribution work cleanly. Baiscally, in a DC, I've got a HA pair of WAN routers (that I have no access to), two Nexus 9300 in a vPC, and a HA Palo Alto firewall pair - all with HSRP, etc. - The Nexus and WAN routers peer using EIGRP to learn the routes for all our sites, and we redistribute (static) routes into EIGRP for the other sites to learn, from both our DCs. That bit's fine. I've set up OSPF on the Nexus and PAs so I don't have to put static routes in 9 fuckin' places (because can't do EIGRP obviously), that bit all works fine too. Then I redistribute EIGRP into OSPF with tags, redistribute OSPF into EIGRP, tagged again, and block those tags from being re-advertised back in on each process. That bit all seems fine, too. The problem is OSPF has a lower AD than EIGRP, so instead of installing routes for all the other WAN sites via the primary WAN router, one of the Nexus switches will install those WAN routes via the other Nexus switch or the PA firewall, which is very Not Ideal. I can't just increase the AD for the OSPF learned routes, because I'll be advertising the same routes at my other DC also, for fail-over purposes, but this one should be preferred until the route doesn't exist anymore. My workaround for this was making a prefix, route-map, and table-map on each Nexus, for it's peer IP, and adding that to OSPF. It works how I'd hope... but this seems super hacky. Is there a better way I should be doing this? Or is this just the expected amount of jank with a design as poor as this?
|
|
#
¿
Mar 6, 2021 01:01
|
|
|
Methanar posted:Sounds pretty jank. You read all that and then assumed we have config management? Absolutely everything is done manually. I'm going to start using eNMS/ansible/Netmiko soon to do some stuff but my junior and me will need to keep it secret because if my bosses find out they'll make us turn it all off. They'd sooner have someone sit there and spend 2 months upgrading switches one by one than having something to do it automatically... And they won't pay for something like Prime either. It's more like static routes will have to go on 6 switches, 4 Palo Alto firewalls and 2 Cisco firewalls. I feel like once the redistribution config is nailed down it shouldn't ever need touching again? It was originally all OSPF. We'd already bought some non-Cisco firewalls. the config was all written up and then my boss decided at the last minute, right before implementation, he wanted it to be EIGRP. I think probably because he doesn't know OSPF (he barely knows EIGRP tbh) even though he's done zero of the implementation or config or daily management of it. Pre- this WAN setup when we had a VPLS with EIGRP and only Cisco devices they were still using static routes in the DCs for no discernible reason. I vaguely remember overhearing somebody saying it's unsecure to use routing protocols on your firewall/DMZ because the hackers can get to all your of network. I didn't bother to argue they could do that anyway since there was static routes for every internal network on them anyway.
|
|
#
¿
Mar 6, 2021 03:23
|
|
|
Too late in the game to change it, they'll never go for it. Especially because we'd have to pay since it's a managed WAN contract. The guy didn't even want any automatic failover for our routing/DCs. I had to slip that bit in too. He genuinely believes it's better for our staff to lose their access to patient information until someone gets called out and changes it manually by putting the static routes in the other DC so he can send an email out saying "IT fixed it  ".
|
|
#
¿
Mar 6, 2021 13:44
|
|
|
My DR and route tagging part works fine. I can advertise a route at both DCs with one of two tags, and it'll be prioritised towards the primary or secondary DC based on which tag I set. The main bit I'm unsure about is the table-map and if there's a better way of avoiding that, but still having one Nexus not learn WAN routes from the other. The other issue with the table map is, if another SVI is added onto these switches and gets advertised into OSPF, I'm probably going to have to block the Nexus peers' SVI IP on each of them on the table-map too.
|
|
#
¿
Mar 6, 2021 17:46
|
|
|
Updated our WLCs last night to fix an ARP bug with AP2802 access points. Only to be met with another bug where locally switched devices can't get an IP after a successful CoA on the same model. I can't upgrade any further because we have 300+ 2600 APs that aren't supported on any other version. Oh and 30 access points disappeared and they're probably stuck in recovery mode, so someone has to drive out and unfuck them manually. I want to cry.
|
|
#
¿
Apr 8, 2021 15:29
|
|
|
I actually did look before hand, that's how I knew not to update to 8.10 or whatever they're up to now or we'd have lost 300 APs, and this new bug is not listed as an open caveat on this version, either.
|
|
#
¿
Apr 8, 2021 16:33
|
|
|
You can also just buy Nexus 9300 fibre and copper pairs and vPC them but that's extra management overhead vs stacking. We paid less than £8k per switch for our 93180s, and bought the 10/25/40gbit SFPs and full copper ones.
|
|
#
¿
Apr 12, 2021 18:10
|
|
|
At my new job we have 2 data centers, each with their own internet and ExpressRoute connection etc. There's also 2x 10gb P2P links between the core switches for replication traffic and user traffic... But they're not used for internet failover, for some reason. DC routing is done using EIGRP, but needs to be changed to accommodate some new firewalls. I wanted to suggest just advertising a tracked, static, default route at the edge device at each DC, but I need them to prefer their local route until it's not there. Would OSPF or iBGP be better for this? My concern with OSPF is it's most likely just going to be all in area 0, and the Core at the backup DC will always prefer the default route from the primary because of the combined 20gbit links and I don't believe I can influence it using tagging, metrics and route-maps, since it's all in the same area? Or can I/is there a better way of picking the preferred one? OSPF would be slightly preferred because we have Meraki devices that use it and would mean we don't need to do any redistribution there. There's no lab VRF or anything here so I want to make sure before I suggest something dumb. Thank
|
|
#
¿
Aug 21, 2021 11:18
|
|
|
falz posted:Ospf as igp and ibgp is made for that. I'd imagine keeping proprietary eirgrp as igp would be fine too if all of your stuff supported it. We're probably going to be replacing a mess of Cisco firewalls/contexts with, hopefully, that doesn't support EIGRP. The end ideal design is: Core - Zone based firewall - Internet routers. Replicated at both sites. There's no eBGP. We're just given a VRRP IP to use as the next hop which would be the default route on our firewalls. We don't need anything fancy really. The hundreds of Meraki sites have a link into both DCs. All the servers are at the primary DC and are in the process of being moved to Azure. If things need to be brought up in the backup DC, they'd just use DNS to handle whatever needs to be accessed over the internet (there's a bunch of WAFs or F5s for that already). Of the P2P drops, the user's at the backup DC should still be able to get to the primary DC over the Meraki SD-WAN. My main concern is advertising the default route in both places, and all the user traffic from the site where the backup DC is (both of these are the main corporate offices for context) will use the P2P to the internet at the Primary DC instead of its own local gateway because I'm not sure what I can do to influence route preference in same area OSPF? Normally I'd use route tagging when redistributing or something but not sure I can do that here?
|
|
#
¿
Aug 21, 2021 17:18
|
|
|
madsushi posted:I run this design for a pair of DCs and it works great. OSPF should prefer the local 0's route over the remote 0's route, since cost is cumulative. Nice one, thank you. This is what I was hoping for. I was just second guessing myself so I don't look dumb. Both cores should have both routes but prefer their own one, until it's not there, is the basic idea. Firewalls will be part of OSPF, internet routers won't be. Ideally it'll be a PA firewall and that will be where I'm advertising the route from... There's a N7K pair with 3 contexts that'll all be in different zones on the PA.
|
|
#
¿
Aug 22, 2021 22:27
|
|
|
If you're changing your radius source IP (and you aren't using any 'default device' feature on your radius server, I'm assuming you're using ISE here) you need to update the network device on there to reflect the new IP - assuming all your routing and firewall policies are how they're meant to be.
|
|
#
¿
Sep 17, 2021 14:31
|
|
|
Meraki have a collection of automation scripts using their own python module. Maybe there's one there that covers your use case: https://github.com/meraki/automation-scripts I haven't done your exact scenario, but my new job uses Meraki and I've been using the API this week to pull a bunch of information from our appliances to add to our NAC. Use the Cisco dev website for the API explorer, it's much easier to find and they give real examples of what a python snippet looks like. I think the GET for the network appliance L7FW is this one: https://developer.cisco.com/meraki/api-v1/#!get-network-appliance-firewall-l-7-firewall-rules There should be a POST in the sidebar nearby. You should download the Meraki python module too so you don't have to write REST calls yourself. If you click the Template bit on the right side of whatever endpoint is correct for your case, it should give you an example using the Meraki python library. Looks like you'll have to format your change as JSON. This is the git for the API: https://github.com/meraki/dashboard-api-python I think some rough steps would be: run the getInventory.py script from Meraki, filter it down in Excel to just the appliances/networkIDs you care about. Take the example script from the Cisco API website to run a GET on one of those you've configured in the UI to how you want it to be so you have the JSON preformatted. Test making the POST request to a test network to make sure it works. When you're certain it's working, take your NetworkIDs and make a list in your python script, then just loop through that list with the working POST request using the JSON data. uhhhhahhhhohahhh fucked around with this message at 17:39 on Sep 21, 2021 |
|
#
¿
Sep 21, 2021 17:29
|
|
|
There's a lot of stuff with Meraki that annoys me. Not being able to push dACL/Group Policy via ISE to any MX appliance. WiFi on MX appliances not supporting RADIUS accounting. Security Group tagging only working on like 1 switch and 2 AP models. All seems very arbitrary.
|
|
#
¿
Sep 24, 2021 23:51
|
|
|
Bob Morales posted:What's the best way to view the configuration of a specific port? Right now I do a show run and just scroll down to it. If it's Cisco you can just add the interface to the show run command: code:
|
|
#
¿
Oct 1, 2021 17:03
|
|
|
|
| # ¿ May 14, 2024 13:41 |
|
|
Where's RADIUS Accounting on MX devices tho... and sending dACL name via ISE.
|
|
#
¿
Oct 12, 2021 20:48
|
|