[114721] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: Multi-homed clients and BGP timers

daemon@ATHENA.MIT.EDU (Steve Bertrand)
Fri May 22 20:26:45 2009

Date: Fri, 22 May 2009 20:26:09 -0400
From: Steve Bertrand <steve@ibctech.ca>
To: Danny McPherson <danny@tcb.net>
In-Reply-To: <A47AAAB1-BEDE-43B3-95FE-5A68A634BFE8@tcb.net>
Cc: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org

This is a cryptographically signed message in MIME format.

--------------ms070809000106070702040404
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Danny McPherson wrote:
> 
> On May 22, 2009, at 5:15 PM, Steve Bertrand wrote:
>>>
>>> neighbor xxx.xx.xx.x timers 30 60
>>>
>>> Make sure that this is communicated to your peer as well so that
>>> their timer setting are reflected the same.
>>
>> Thankfully at this point, we manage all CPE of any clients who peer with
>> us, and so far, the clients advertise our own space back to us. I'll go
>> back to looking at adequate timer settings for my environment.

> Of course, given that the lowest BGP holdtime is selected
> when the session is being established, you don't really need
> to change the CPE side, all you need to do is make the
> change on the network side and reset the session.  And it's
> typically a good idea to set the keepalive interval to a
> higher frequency when employing lower holdtimes such that
> transient keepalive loss (or updates, which act as implicit
> keepalives) don't cause any unnecessary instability.
> 
> Also, there are usually global values you can set for all
> BGP neighbors in most implementations, as well as the per-peer
> configuration illustrated above.  The former requires less
> configuration bits if you're comfortable with setting the
> values globally.

I remember reading that the lowest value is implemented, but thanks for
the reminder. In this case, since I *can* change it at the CPE, I may as
well. That way, in the event that I move on (or get hit by a bus) and
the next person moves the connection to a new router, the CPE will win.

Also... the global setting is a great idea. Unfortunately, connected to
this router that handles these fibre connections are a couple of local
peers that I don't want to change the 'defaults' for.

I can't remember if timers can be set at a peer-group level, so I'll
look that up and go from there. That will be my best option given what
is connected to this router.

> If you want to converge a little fast than BGP holdtimes here
> and the fiber link is directly between the routers, you might
> look at something akin to Cisco's "bgp fast-external-fallover",
> which immediately resets the session if the link layer is
> reset or lost.

Well, unfortunately, the local PUC owns the fibre, and they have a
switch aggregating all of their fibre in a star pattern. They then trunk
the VLANs to me across two redundant pair. I'm in the process of
persuading them to allow me to put my own gear in their location so I
can manage it myself (no risk of port-monitor, no risk of their ops
fscking up my clients etc). This way, they connect from their
client-facing converter into whatever port in my switch I tell them.

With that said, and as I said before, L3 and below rarely fails. I'll
look into fast-external-fallover. It may be worth it here.

> 
>> While I'm at it, I've got another couple of questions:
>>
>> - whatever technique you might recommend to reduce the convergence
>> throughout the network, can the same principles be applied to iBGP as
>> well?
> 
> Depending on your definition of convergence, yes.  If you're
> referring to update advertisements as opposed to session or
> router failures, though, MRAI tweaks and/or less iBGP hierarchy
> might be the way to go.  Then again, there are lots of side
> effects with these as well..

I suppose I might not completely understand what I am asking.

- pe1 has iBGP peering with p1 and p2, and pe1 has p2 as it's next hop
in FIB for prefix X (both cores have prefix X in routing table through a
different edge device)
- p2 suddenly falls off the network

Perhaps it's late enough on Friday night after a long day for me to not
be thinking correctly, but I can't figure out exactly what the delay
time would be for a client connected to pe1 to re-reach prefix X if p2
goes down hard.

>> - if I need to down core2, what is the quickest and easiest way to
>> ensure that all gear connected to the cores will *quickly* switch to
>> preferring core1?
> 
> Use your IGP mechanisms akin to IS-IS overload bit or OSPF
> stub router (max metric) advertisement.

I will certainly look into your suggestions. I have only a backbone area
in OSPF carrying loopbacks and infrastructure, but don't quite
understand the entire OSPF protocol yet.

Thanks Danny,

Steve

--------------ms070809000106070702040404
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII/zCC
AtowggJDoAMCAQICEEs5xg/J3t77QWJ4SatV1HcwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDUwNzIzMTYxMFoX
DTEwMDUwNzIzMTYxMFowQjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEfMB0G
CSqGSIb3DQEJARYQc3RldmVAaWJjdGVjaC5jYTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
AQoCggEBAJSTRAjP1RVa87/mnZn+PBTbENgyhhBJ4rWApmaNcthzRdk2DB/49KrXx3EQP60w
Lj4KU0DFkiGNVj9BnVxRAx/WDXKxGC3uGGEG6gjyWv8KFMWMsH9mL7y7uNow1HueT6pZUf9o
yY8Ewd+01QpGi7FfXOae7lGHhbEwnEJGwz08ytRfLmH0KtEzlZanZZhwDGX5s1kIHnyxdACh
3byXY6Z2bOrx0rcrQHCnHJppxddR60F7igjaMuBFstE51h9XTgXDNKJbglqTug5ghGihNuP6
VsBN7ue62y96UGIE22TvKEcAQ665vQGjHqZeSzZYy+hWNOa27pWFmhlqFjx0x8MCAwEAAaMt
MCswGwYDVR0RBBQwEoEQc3RldmVAaWJjdGVjaC5jYTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3
DQEBBQUAA4GBAMOmjxjp2Xzk6ZHLwTgFDzVhm98RjRT3UXotKjNIR7SgwfWF5wkJrx4I+dXu
ui5ztMEq4bTTRgJ344MqE6uZiZlg+tBIFHZGCJfKdzsX4QuV2jmw0sR5dMaYxG6tlDB0YUMv
gTqzV7ZDpiusTMOZe9pP1PdxFhOcIJXtMQDj5LhuMIIC2jCCAkOgAwIBAgIQSznGD8ne3vtB
YnhJq1XUdzANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl
IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt
YWlsIElzc3VpbmcgQ0EwHhcNMDkwNTA3MjMxNjEwWhcNMTAwNTA3MjMxNjEwWjBCMR8wHQYD
VQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMR8wHQYJKoZIhvcNAQkBFhBzdGV2ZUBpYmN0
ZWNoLmNhMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAlJNECM/VFVrzv+admf48
FNsQ2DKGEEnitYCmZo1y2HNF2TYMH/j0qtfHcRA/rTAuPgpTQMWSIY1WP0GdXFEDH9YNcrEY
Le4YYQbqCPJa/woUxYywf2YvvLu42jDUe55PqllR/2jJjwTB37TVCkaLsV9c5p7uUYeFsTCc
QkbDPTzK1F8uYfQq0TOVlqdlmHAMZfmzWQgefLF0AKHdvJdjpnZs6vHStytAcKccmmnF11Hr
QXuKCNoy4EWy0TnWH1dOBcM0oluCWpO6DmCEaKE24/pWwE3u57rbL3pQYgTbZO8oRwBDrrm9
AaMepl5LNljL6FY05rbulYWaGWoWPHTHwwIDAQABoy0wKzAbBgNVHREEFDASgRBzdGV2ZUBp
YmN0ZWNoLmNhMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAw6aPGOnZfOTpkcvB
OAUPNWGb3xGNFPdRei0qM0hHtKDB9YXnCQmvHgj51e66LnO0wSrhtNNGAnfjgyoTq5mJmWD6
0EgUdkYIl8p3OxfhC5XaObDSxHl0xpjEbq2UMHRhQy+BOrNXtkOmK6xMw5l72k/U93EWE5wg
le0xAOPkuG4wggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJa
QTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoT
EVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERp
dmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG
9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcN
MTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRp
bmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp
bmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f
6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/Ef
kTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7
AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRw
Oi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8E
BAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqG
SIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQc
UCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bG
CE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDZDCCA2ACAQEwdjBiMQswCQYD
VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE
AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEs5xg/J3t77QWJ4SatV
1HcwCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B
CQUxDxcNMDkwNTIzMDAyNjA5WjAjBgkqhkiG9w0BCQQxFgQUYrU8q+rO1o5PJr9JhIr7tkfy
MicwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZI
hvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjEL
MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq
BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBLOcYPyd7e+0Fi
eEmrVdR3MIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG
cmVlbWFpbCBJc3N1aW5nIENBAhBLOcYPyd7e+0FieEmrVdR3MA0GCSqGSIb3DQEBAQUABIIB
AHBoxLz6BjCwfKHcQ2X48a9iwFBGk2Ut7PHeqKzcp6Imn5Nz8QycNY9qLcc/u/PWbTOlF9X0
nzvW/FUgRGaKPU8M8o2wkZRLnNTrm0ZS0E2dZA1kKtzdhnOt9ucqZNjSq7IgCLzqo2Zj4xqy
oEpZM200CQdC3ZgUc/UBLbEuDMjWiMxWNg8zFWgHz4VhVqGJfYpYvgUB7lf50qzLg85uF15/
+1yPaNrRYSCR67WepQfXMIAOmRfChs7gWv+pfX0re+946xXepRR3b05P56Owi02DCMtqSYum
sws5J5DfTQAAsN0vqFOPngK8t4pfcQY8BZNiWAOZWq0/8jCoGplI+qEAAAAAAAA=
--------------ms070809000106070702040404--


home help back first fref pref prev next nref lref last post