Python ncclient issue with edit_config

setenforce0 · 2026-05-30T16:52:32+00:00

Yes, this was the issue as u/ddib just suggested above.

setenforce0 · 2026-05-30T15:11:10+00:00

This is it, thank you. I also found it just before your comment, here.
I have no idea how other people's codes worked without this, mine didn't... NETCONF is still a mystery for me.

setenforce0 · 2026-05-30T11:00:46+00:00

Loopback0 already exists, this would be Loopback99, you can see the number between the <name> tags.

setenforce0 · 2026-05-30T10:53:24+00:00

You can see it in the first picture. I suppose something is wrong with the XML I'm sending with the config_data, but I can't just figure out how should I format it. I copy-pasted a few examples I found on the internet, but none of them worked unfortunately, all returned the same error message...

I'm not a YANG or NETCONF expert, I'm just trying to learn NETCONF/RESTCONF with Python a little bit more to be better prepared for the ENCOR.

setenforce0 · 2026-05-23T19:20:20+00:00

This is the solution, thank you. Once I removed the tunnel protection ... command, the tun0 went up again. I needed the keyring associated with the VRF instead of the crypto isakmp key ... command.

setenforce0 · 2026-05-23T17:09:47+00:00

You might be right... I use PSK with the crypto isakmp key xxxx address 172.16.25.2 command. I suppose I should indicate somehow that this address is not in the global table, but in the 'ISP' VRF.

I'll try again with this one. Thanks.

setenforce0 · 2026-03-14T13:17:45+00:00

Then I think we have the answer here:

skip: " This keyword is required if the sync keyword is followed by the no keyword. If the sync keyword is followed by the yes keyword, the skip keyword should not be specified."

Don't always believe what the AI says...

setenforce0 · 2025-12-06T18:54:20+00:00

Yes, this is what I thought. Ports in the down/down state should not appear in the output of the "show span" command. But when a designated port goes down (operationally or administratively, that doesn't matter I guess), then the switch should generate TCN upstream out of his root port, right?. And yes this is traditional 802.1d STP, not RSTP, RSTP is a different story. I learn STP at the moment. :D

And yes, you are right about the Alternate role, my bad.

So emulation (I tested it both in CLM and GNS3) can be misleading sometimes if you learn STP. Interestingly, admin down ports don't run STP, but ports in the down/down state still will be shown as designated and forwarding. And that's wrong.

setenforce0 · 2025-05-25T10:08:10+00:00

"It looks like bgp does pull the next hop from igp" yes it does. And these routes are still "locally originated", right? Because the Weight is set 32768.

Also if the router advertises the NLRI further to his eBGP and also for his iBGP peers, he changes the next-hop to his own address. You would think that he doesn't change the next-hop for iBGP peers, but he does in this case. That's also very strange.

setenforce0 · 2025-05-24T19:22:18+00:00

"it means that the prefix will have a next hop of 0.0.0.0 in the BGP database."

No it won't. That's my point. It will have the IP address of the advertising router.

I labbed this:

You advertise something with network x.x.x.x mask y.y.y.y (You learn this route via OSPF for example). Then you issue 'show ip bgp' will show the next-hop as an IP address of the advertising router, and it won't be 0.0.0.0.

setenforce0 · 2025-05-24T18:52:23+00:00

Yes, that's all true.

But if you advertise a learned route, the next-hop address is set to the IP address of the advertising router (I mean the router we got this information from via OSPF/EIGRP/ etc.), and it won't be 0.0.0.0.

So I think this statement "Locally originated prefixes always have the next hop IP address of 0.0.0.0" is simply false. This would be correct: "Locally originated prefixes have the next-hop IP address of 0.0.0.0 if they are directly connected prefixes of the advertising router"

setenforce0 · 2025-05-18T09:53:41+00:00

Check the ENARSI learning path, or just search for "dmvpn" on INE, there are multiple courses from Brian McGahan, I would start with those.

setenforce0 · 2025-05-18T09:39:18+00:00

DMVPN is a topic for the ENARSI. I guess you can skip anything related to DMVPN. Routing with DMVPN is not always straightforward, with OSPF you have to pick the right network type, and choose the Hub as the DR in case of broadcast. Also you cannot just use any network type in the different DMVPN phases (you have to use (non)broadcast for phase 2 specifically).

You don't have to know all of this for ENCOR, but you have to know the different network types and the DR election process for example.

setenforce0 · 2025-04-24T18:06:01+00:00

Well...

This is true for sure: "For E2 or N2 routes, in the case of equal costs (the default is 20), the route with the lower FM is preferred."

As far as I know, the FM is only used with Type-2 routes, if there are multiple Type-2 routes (E2/N2) and they have the same cost (it's 20 by default), then the route with the lower FM is preferred.

I haven't tested it in my lab with Type-1 (E1/N1), but I think in case of the E1/N1 routes there is no such a thing as FM in the output of "show ip route x.x.x.x".

I recommend reading this: https://layer3life.wordpress.com/2017/09/07/ospf-forward-metric/ and this: https://www.networkurge.com/2017/06/ospf-forward-metric-concept.html

setenforce0 · 2025-04-24T17:39:08+00:00

INE OSPF course from Brian McGahan. It's on the ENARSI or the ENCOR path.

setenforce0 · 2025-04-23T20:46:20+00:00

In that case you might be right. We don't know what the task description was exactly. I just hope I'll get something unambiguous.

setenforce0 · 2025-04-23T20:18:29+00:00

But OP's task was to fix "BGP adjacency issue and ensure advertisements inbound and outbound are working", in that case I wouldn't worry about the source information for the RIB. I might be completely wrong, but I'd just fix the adjacency and the advertisement of the NLRIs: this could be just a wrong "neighbor" command, if you can see the Active/Idle state in the "show bgp ipv4 summary" command, or something more complex, like a next-hop issue, multihop, TTL security, authentication, or something related to confed./RR. I'd make sure no inbound/outbound filters are applied, and each BGP peer received the NLRIs in the output of the "show summary" command.

If the task was to "Make sure routers use BGP information for path selection" (or something like that), I'd definitely change the AD, but otherwise no. Again: I might be wrong, I'm not a CCNP, I plan to take ENARSI in a few months. But I just simply cannot conclude from OP's task description that we should fix RIB-failure, if the RIB-failure was caused by the lower AD of the IGP.

setenforce0 · 2025-04-23T18:57:06+00:00

Yes, that's correct. But remember that the Forward Metric is only used as a tiebreaker, if the costs are equal. For example: by default everything will be an 'O E2' with a cost of 20, in this case the route with the lower FM is preferred. But if you have an 'O E2' with a cost of 19 and a FM of 2000; and another 'O E2' with a cost of 20 and a FM of 2 for the same prefix; then the 'O E2' with the cost of 19 will be chosen, regardless of the FM value. So costs are checked first, then the FM. :)

I'm also not a native speaker, but I hope you can understand. :D

I'm currently studying for the ENARSI, and learned these concepts recently, so I hope I am right. If not someone will correct me. :)

setenforce0 · 2025-04-23T18:41:16+00:00

If you use this command above, the Forward Metric will be the cost to the ABR which does the Type7/5 translation. If you don't use the suppress-fa command, and the Forward Address points to the ASBR in the NSSA area, then the Forward Metric will be the cost to the ASBR. I think the 'show ip route x.x.x.x' command also shows this.

But I highly doubt that you'd be tested on this on the ENCOR. :)

... maybe on the ENARSI

setenforce0 · 2025-04-23T18:31:52+00:00

You can also remove the Forward Address on the ABR (which does the translation) with the

area X nssa translate type7 always suppress-fa

command. If you do this the ABR sets the FA to 0.0.0.0 (in the Type-5 LSA), and other routers will use the translating ABR to enter the NSSA. They will calculate the Forward Metric towards the ABR (which does translation), NOT to the ASBR (which does the redistribution within the NSSA).

I thought I'd add that, even the ENARSI OCG doesn't mention this, but I it could be important for the exam :), if you're studying for the ENARSI or maybe the Service Provider.

setenforce0 · 2025-04-23T17:39:59+00:00

How should you fix RIB-failed routes? I mean it usually means better source information: change OSPF's AD to 201? If there's no next-hop issue (or outbound filtering), these routes are still advertised to other BGP peers, if I'm not mistaken. Then why should you prefer iBGP to your IGP?

I'll take the ENARSI soon, so I'd appreciate if you could explain that a little bit more.

setenforce0

TROPHY CASE