Update-source null is not available

This wasn't required in this type of configuration in previous versions of IOS in the past. I don't think it's related to your situation, but if it's a bug this might help.

Perhaps there is some reason it doesn't believe it's actually directly connected. I interpret this error message as "the update-source points to an interface that doesn't exist on this machine, or is down" like "update-source loop1" and you only have "loop0". So it can't get an IP address, and fails.

BGP neighbor will not come up if it is using a default route to reach a neighbor, try changing that to something more specific. When the Configuration Manager client needs to process a software update scan, Scan Agent creates a scan request based on the available policy as noted in ScanAgent. Location Services creates a location request and sends it to the management point.

In LocationServices. After getting the results from the stored procedure, the management point sends a response to the client. Location Services parses the response and sends the location back to Scan Agent. Scan Agent now has the policy and the update source location with the appropriate content version. In ScanAgent. WUAHandler adds the update source to the registry. It initiates a Group Policy refresh if the client is in domain to see whether Group Policy overrides the update server that's added.

The following entries are logged in WUAHandler. In WindowsUpdate. For an existing client, we could expect to see the following message in WUAHandler. After the update source is successfully added, Scan Agent raises a state message and starts the scan. If not, install and configure a software update point and monitor SUPSetup. For more information, see Install and configure a software update point.

For more information about software update scan failures troubleshooting, see Troubleshoot software update scan failures. A scan may result from:. Scan results will include superseded updates only when they're superseded by service packs and definition updates. In WUAHandler. Review WUAHandler. If no new entries occur, it indicates that no SUP is returned by the management point.

To fix such issues, see Scan failures due to missing or corrupted components. There's a known issue that a bit Windows 7 ConfigMgr R2 client requesting an update scan fails to return scan results to Configuration Manager. It causes the client to report incorrect compliance status and the updates fail to install when Configuration Manager requests the update cycle. However, if you use the Windows Update control panel applet, the updates usually install fine. When you're experiencing this problem, you receive a message similar to the following one in WindowsUpdate.

It's a memory allocation issue, bit Windows 7 computers won't see this error since their address space is effectively unlimited. However, they'll exhibit high memory and high CPU usage, possibly affecting performance. X86 clients will also exhibit high memory usage usually around 1. When troubleshooting scan failures, check the WUAHandler. More information about the error can be found in WindowsUpdate.

To understand how to read WindowsUpdate. Your best source of information will come from the logs and the error codes they contain. For more information about the error codes, see Windows Update common errors and mitigation.

If the client can't communicate with the WSUS computer, the scan will fail. This issue can happen for many reasons, including:. To fix these issues, see Scan failures due to proxy-related issues. If the WSUS computer isn't returning the error, the issue is likely with an intermediate firewall or proxy. Here are the steps:.

The software updates feature automatically configures a local Group Policy setting for the Configuration Manager client so that it's configured with the software update point source location and port number. You have not given us much detail about your environment but it does sound like the default behavior of BGP is working ok for you. R1's loopback However, If i want to use tunnel of R1 to establish BGP neighborship with R2 tunnel , Do i also need to add 'bgp update source tunnel' cmd?

My understanding that the reason is same as use the loopback inteface. Actually,there is no need to add this cmd. In your 1 where a decision was made to establish BGP peering using loopback interfaces then yes you would need to specify the source address.

In your 2 where the decision was to establish BGP peering using the tunnel there is not a need to specify the source address because the default choice of address works well for you.

If it is then you do not need to specify update source and if it is not then you probably need to specify update source. Perhaps the key question is whether the address that your neighbor wants to peer with is the address of the interface that you will use to reach the peer. If yes then you do not need update source and if no then you do need update source. Actually i want to know the difference between using loopback and tunnel to establish neighborship, I have to specify update source for using lookpback, then why i do not need to specify update source for using tunnel.

This is what i want to ask. I look your reply carefully and understanding is that update source for BGP OPEN packet is the closest outgoing interface to reach a neighbor by default. Let me try again from a slightly different perspective. It may seem a bit picky but I want to start with part of your statement in the original post "because of BGP uses the ip address configured on the physical interface".

It is not necessarily a physical interface. In your case where the connection is a tunnel then the address of the virtual interface would be used. Perhaps another way to look at this question is to look at the relationship between the BGP peer address and the interface addresses of your router. When the peer address is in the same subnet as a router interface address as is the case with your tunnel then you do not need update source.

And when the peer address is not in the same subnet as an interface address as is the case with the loopback then you probably do need the update source. I am glad that you can reply again and Thanks for giving me another way to make me more deeply understand the update source for bgp packet. But you said ' peer address is not in the same subnet as an interface address then you probably do need the update source' I may not agree with you.

I think it's not exactly. Depending on scenarios, you may need what Richard suggested. In scenario that you mentioned, it does not need update source mentioned as there is only one available egress interface to reach the negihbor. R Assume metric on R1 interface connecting R2 is 10 and metric on R3 interface connecting R2 is Rest all are 1. Assume you configured So R1 will use R4 as nexthop to reach Similarly, R3 will use R4 as nexthop to reach In above scenario, the session will not come up and you need update-source enabled to make it up.

My understanding is as below,if there is something wrong,please point it out and correct it. We need to consider if there are existing multiple interfaces or multiple paths between two BGP peers. For the most part this is a good understanding. I would add that sometimes when there is only a single path to the neighbor but the neighbor is multiple hops away it is helpful to specify the update source.

Also sometimes when the neighbor is IBGP it is helpful to specify update source even if it has only a single path. Your understanding is right. Buy or Renew.