|
Can anyone point me in the direction of where the XML schema or whatever that Cisco uses for Netconf is documented? I just want something that shows how each part of the config is represented.
|
#
?
May 2, 2019 05:43
|
|
|
|
| # ? Apr 24, 2024 14:36 |
|
|
show run | xml is your best bet
|
|
#
?
May 2, 2019 14:44
|
|
|
Pile Of Garbage posted:Can anyone point me in the direction of where the XML schema or whatever that Cisco uses for Netconf is documented? I just want something that shows how each part of the config is represented. You mean the YANG models? https://github.com/YangModels/yang/tree/master/vendor/cisco
|
|
#
?
May 2, 2019 14:59
|
|
|
tortilla_chip posted:show run | xml is your best bet That output modifier doesn't appear to be available on the CSR 1000v I've been testing with (Running IOS XE 16.09). ragzilla posted:You mean the YANG models? Yeah I'd seen that repo before but it just confused me till I realised they're model definitions. I ended up using pyang to parse the definitions which worked well (Example).
|
|
#
?
May 3, 2019 05:36
|
|
|
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
|
|
|
How far away are those datacenters? What does the trunk port you reference run over? Is it actually running over MPLS only? I can't say the design below is bad, as I am not qualified to judge other peoples designs, but it is very different than what I would design. You should really just have separate subnets at each location and stop trying to stretch layer 2, unless they are super close and you have gigabit or better with very low latency between them.
|
|
#
?
May 4, 2019 21:01
|
|
|
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
|
|
|
Are you doing anything to filter broadcast or proxy MAC discovery between the two sites?
|
|
#
?
May 4, 2019 21:48
|
|
|
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
|
|
|
e: nm
Woof Blitzer fucked around with this message at 17:49 on May 11, 2019 |
|
#
?
May 9, 2019 00:09
|
|
|
Why would Cisco Emergency Responder work with Catalyst 9300-9400s but not 9200s? I guess my question is what the hell is wrong with Cisco. Hopefully there is an early code release or something I can use to get these working.
|
|
#
?
May 16, 2019 20:50
|
|
|
I wouldn’t hold your breath on that - if the 9200 isn’t newer they don’t seem to go back and add things. It’s not a very good program it just checks the “E911” checkbox for Cisco sales
|
|
#
?
May 17, 2019 18:21
|
|
|
BaseballPCHiker posted:Why would Cisco Emergency Responder work with Catalyst 9300-9400s but not 9200s? I guess my question is what the hell is wrong with Cisco. Hopefully there is an early code release or something I can use to get these working. What isn’t working, port location? You should be able to use subnet pools if that’s the case.
|
|
#
?
May 17, 2019 18:33
|
|
|
Partycat posted:I wouldn’t hold your breath on that - if the 9200 isn’t newer they don’t seem to go back and add things. Well bugger. I emailed our sales rep just to see if he had any inklings, but yeah probably a lost cause. Bigass Moth posted:What isn’t working, port location? You should be able to use subnet pools if that’s the case. Bingo. Will have to setup with subnet pools as an alternate I guess. Just doesnt make sense that they'd support 9300 and 9400s but not the 9200 within that same series of switches.
|
|
#
?
May 17, 2019 20:26
|
|
|
I’ve seen how it works internally to some extent, there is just config that identifies the hardware by OID and the appropriate tables to poll interfaces and CDP data - there is a CAM option too but I don’t know what that does to be honest. As was said layer 3 if that suits your ERL boundaries , or manual extensions if your phones don’t move.
|
|
#
?
May 17, 2019 20:51
|
|
|
Just avoid the entire NCS line. Optical BU or routing BU. It is all poo poo. The NCS5501 running as a NV satellite off an ASR9k can't bring link up on a sub 10gbit port unless autonegotiation is enabled and working. How could someone think that is a reasonable limitation for a carrier edge box? This fact is buried as an one liner that makes no sense, unless you already found this "feature," in a 300 page document.
|
|
#
?
May 18, 2019 15:11
|
|
|
FatCow posted:Just avoid the entire NCS line. Optical BU or routing BU. It is all poo poo.
|
|
#
?
May 18, 2019 15:23
|
|
|
FatCow posted:The NCS5501 running as a NV satellite off an ASR9k can't bring link up on a sub 10gbit port unless autonegotiation is enabled and working. How could someone think that is a reasonable limitation for a carrier edge box? This fact is buried as an one liner that makes no sense, unless you already found this "feature," in a 300 page document. On the one hand that is a silly limitation, but on the other hand I have a severe hatred for the fact that so many dumbass carriers insist on disabling autonegotiate. It's not loving 1995, hardcoding speed/duplex is for chumps.
|
|
#
?
May 18, 2019 15:34
|
|
|
adorai posted:I love my (former) SE, I email him with any weird issue I come across and he almost immediately replies with poo poo like, "didn't you see this on page 157 of the 2nd revision of the documentation?" It's like he has it memorized. One of the CCIEs I work with is like that too. I also trust him 100% to be right and he’s never proven me wrong. I wish I had that level of information retention.
|
|
#
?
May 18, 2019 18:01
|
|
|
wolrah posted:On the one hand that is a silly limitation, but on the other hand I have a severe hatred for the fact that so many dumbass carriers insist on disabling autonegotiate. It's not loving 1995, hardcoding speed/duplex is for chumps. It's not even that. If Master/slave clock negotiation fails it won't bring the port up either.
|
|
#
?
May 18, 2019 18:16
|
|
|
FatCow posted:Just avoid the entire NCS line. Optical BU or routing BU. It is all poo poo. I’ve got some 5501s running stand-alone collapsed distribution/edge/peering and they work decently for that.
|
|
#
?
May 19, 2019 13:26
|
|
|
That's likely our next play, but nV satellite had some significant benefits on cost/licensing.
|
|
#
?
May 19, 2019 21:03
|
|
|
What is everybody doing in terms of traffic management now that loads of apps do cert pinning and business-critical apps might talk to the same cloud endpoints as loads of other lovely traffic? Do we just pour money into the Internet connections so there's never any bottleneck? Do we inspect the SSL traffic and have somebody on-hand to add exceptions when it breaks certain apps? Put a proxy in front of all the devices on the corporate network?
|
|
#
?
May 21, 2019 19:37
|
|
|
wolrah posted:On the one hand that is a silly limitation, but on the other hand I have a severe hatred for the fact that so many dumbass carriers insist on disabling autonegotiate. It's not loving 1995, hardcoding speed/duplex is for chumps. As I got told by some telco people, it's not because they don't want to, it's because of lawsuit(s) in the past so legal forces them to turn it off. People loooove suing the telcos (generally for good reason though). Basically: Port comes up at wrong speed/characteristics and has sub-optimal settings. Someone notices 4 months later, and client goes apeshit saying "telco x didn't give us the service level we bought, give us 4 months refund+damages". So now it's hard code everything facing customers (ie: revenue interfaces).
|
|
#
?
May 21, 2019 21:29
|
|
|
I swear we discussed this here a year or so ago - there’s a reason to leave it off if the port goes down hard when there’s a problem and that’s the preferred operative mode . If it falls back to another condition like 1000T/Full to 100T/Full with a wire open, and you don’t notice, then yeah that’s not good. I think we are somewhat safe at this point to refer this towards things other than the 10/100 negotiating that people would gently caress up by picking the “fastest” one and breaking things .
|
|
#
?
May 21, 2019 22:04
|
|
|
It's no harder to monitor for link mode than it is to monitor for link state. Anyone who gives those reasons as excuses is being really lazy IMO. The other problem I have with that idea is that there's no technical reason the equipment couldn't advertise only one mode in autonegotiation, so it both worked without requiring any pointless manual configuration and only operated in the desired mode.
|
|
#
?
May 22, 2019 02:58
|
|
|
wolrah posted:The other problem I have with that idea is that there's no technical reason the equipment couldn't advertise only one mode in autonegotiation, so it both worked without requiring any pointless manual configuration and only operated in the desired mode. This. If you're thinking of AT&T's metro ethernet products, you can actually request they do exactly this ^^^: "please set my port to auto-negotiate advertising only 100/full" on a 100mbit port. The other half of the reason why is because they wrote their design document back when Fastethernet was the copper standard and simply never updated them to reflect that "Fastethernet" doesn't exist on gigabit Ciena/Juniper/Cisco hardware ports.
|
|
#
?
May 22, 2019 05:43
|
|
|
CrazyLittle posted:This. If you're thinking of AT&T's metro ethernet products, you can actually request they do exactly this ^^^: "please set my port to auto-negotiate advertising only 100/full" on a 100mbit port. Just like using DHCP reservations instead of hardcoded static IPs, any time you can reduce the amount of manual configuration required you eliminate opportunities for human error while simultaneously making the system somewhat self-documenting. Everybody wins, except a few "we've always done it this way and change is scary" types.
|
|
#
?
May 22, 2019 14:43
|
|
|
CrazyLittle posted:The other half of the reason why is because they wrote their design document back when Fastethernet was the copper standard and simply never updated them to reflect that "Fastethernet" doesn't exist on gigabit Ciena/Juniper/Cisco hardware ports. Just ran into this (on the provisioning info documents) on a 10Gb MIS Service, they wanted to know if I wanted 1000BaseLX or 1000BaseSX handoff.
|
|
#
?
May 22, 2019 19:51
|
|
|
Studying for a CCNA but I've never taken a Cisco test before. I'm getting anxious about level of detail. Any representative practice tests out there? Like, is knowing what QoS DSCP codes are enough? Or do I need to memorize the most important ones, too? That sort of thing. It feels like there's a bottomless well of protocols and tables I could memorize.
|
|
#
?
May 24, 2019 21:17
|
|
|
CrazyLittle posted:This. If you're thinking of AT&T's metro ethernet products, you can actually request they do exactly this ^^^: "please set my port to auto-negotiate advertising only 100/full" on a 100mbit port. Yeah, I just experienced this at a new site with metro Ethernet. Our “100mb symmetrical” link was auto negotiating to 100/half duplex giving us like 10mb actual speed. Got to experience the hell that is ATTs support too, after 3 auto closed tickets they finally fixed it. I dont think the speed 100 was an actual problem but it negotiates at 1000/full now and speeds are what I expected.
|
|
#
?
May 24, 2019 21:27
|
|
|
Working with some SonicWALLs, I'm familiar with them but haven't really touched more advanced features... until now. Trying to implement bandwidth management and I'm having issues finding something out for sure. If I create a BWM object and apply it to multiple policies, is the bandwidth shared across all those policies? i.e. I guarantee 5Mb and limit to 10Mb maximum, will it allow each policy to hit a maximum of 10Mb, or will it share that 10Mb across all policies? I am assuming it's shared, but this customer's circuit is ridiculously under-speced so it's maxed constantly even after applying limitations to a bunch of different policies.
|
|
#
?
May 29, 2019 20:49
|
|
|
If you apply a 5Mb limit on multiple firewall rules then each traffic handled by each rule shares that 5Mb, not 5Mb total across all rules. If you do them in an app control policy then you should be able to set the limit and choose the bandwidth management action object to be a shared 5Mb across all the affected policies. Having to take wildly different approaches to what seem like small requirements changes is one of the most infuriating things about Sonicwalls.
|
|
#
?
May 29, 2019 21:46
|
|
|
Thanks Ants posted:If you apply a 5Mb limit on multiple firewall rules then each traffic handled by each rule shares that 5Mb, not 5Mb total across all rules. If you do them in an app control policy then you should be able to set the limit and choose the bandwidth management action object to be a shared 5Mb across all the affected policies. Yeah, after screwing around with it for a bit more yesterday I realized that the BWM objects are shared bandwidth. Working with these makes me miss Fortigate devices a lot.
|
|
#
?
May 30, 2019 17:13
|
|
|
MF_James posted:Working with these makes me miss Fortigate devices a lot. Harsh
|
|
#
?
Jun 2, 2019 15:35
|
|
|
FatCow posted:Harsh Hey, when it works, it works really well. But when it doesn't, then Fortinet makes you go on a Spirit Quest. The destination of which is *always* "Yeah, we've known about this for the last several revisions but were hoping it would fly under the radar until the next major FortiOS release" Even then, they'll only help you if you either pay a poo poo ton of money OR buy a LOT of their hardware already. Usually it requires both. I can remember an issue we had years and years ago with them (I want to say it had to do with DHCP pools). We had to threaten to walk away from an already installed base of around 2300 60C/60D. While they made a fix, it was a fix for our company only and if I recall it took them over two years to roll it into their public branch of FortiOS.
|
|
#
?
Jun 2, 2019 15:53
|
|
|
During my brief brush with MSPing I first came into contact with Fortinet and Ubiquiti gear. This accident of timing probably makes Fortinet seem worse than it really is.
|
|
#
?
Jun 2, 2019 16:20
|
|
|
BaseballPCHiker posted:Why would Cisco Emergency Responder work with Catalyst 9300-9400s but not 9200s? I guess my question is what the hell is wrong with Cisco. Hopefully there is an early code release or something I can use to get these working. So put in a TAC case and asked our Cisco rep about this. Basically they have no plans to support CER with 9200s. So we're using IP subnets which works for most of our sites, but we have a few places with different physical locations on the same subnet, which means we'll just have to manually add in phones there.
|
|
#
?
Jun 7, 2019 15:24
|
|
|
In my experience Fortinet products are one of the least terrible UTM boxes
|
|
#
?
Jun 7, 2019 16:20
|
|
|
|
| # ? Apr 24, 2024 14:36 |
|
|
BaseballPCHiker posted:So put in a TAC case and asked our Cisco rep about this. Yeah that’s a pain in the rear end to manage depending on your nomadic roaming policy (or reality). Ah well.
|
|
#
?
Jun 7, 2019 16:37
|
|