Hi all, I have a doubt about the bellow scenario, where the ISP1 use eBGP sessions to its peers and is a BGP Transit AS. NSP 1 ------------------ ISP 1 Router2 ----------- NSP 2 | | | | | | | annunce /21 | | | Customer1 --------------- ISP 1 Router1 announce /20 The "Customer1" is client on both ISPs (ISP1 and NSP1) and have an /20 IP prefix. To NSP1, it announce two /21 prefixes. To ISP1, it announce a /20 prefix. If traffic comes from NSP 2 (connected only to ISP 1) to Customer1, the ISP 1 Routers try to send data over NSP 1, ignoring the Custormer1->ISP1 link. To solve this question, an solution that I found is filter Customer1 prefixes in BGP session between NSP1 and ISP1 Router2. But this don't appear scalable... Is this solution right ? What is the better solution for this scenario? How large ISPs solve this kind of problem? Thanks, Rafael
-----Original Message----- From: Rafael Ganascim [mailto:rganascim@gmail.com] Sent: Thursday, May 20, 2010 11:25 AM To: nanog@nanog.org Subject: BGP Transit AS
Hi all,
I have a doubt about the bellow scenario, where the ISP1 use eBGP sessions to its peers and is a BGP Transit AS.
NSP 1 ------------------ ISP 1 Router2 ----------- NSP 2 | | | | | | | annunce /21 | | | Customer1 --------------- ISP 1 Router1 announce /20
The "Customer1" is client on both ISPs (ISP1 and NSP1) and have an /20 IP prefix. To NSP1, it announce two /21 prefixes. To ISP1, it announce a /20 prefix. If traffic comes from NSP 2 (connected only to ISP 1) to Customer1, the ISP 1 Routers try to send data over NSP 1, ignoring the Custormer1->ISP1 link. To solve this question, an solution that I found is filter Customer1 prefixes in BGP session between NSP1 and ISP1 Router2. But this don't appear scalable...
Is this solution right ? What is the better solution for this scenario? How large ISPs solve this kind of problem?
The more specific /21's are winning over the /20, so they will always be preferred by default. If you want to change that, you could announce the /20 to NSP1, or announce the /21's to ISP1. Mike
On 2010-05-20 11:25, Rafael Ganascim wrote:
Hi all,
I have a doubt about the bellow scenario, where the ISP1 use eBGP sessions to its peers and is a BGP Transit AS.
NSP 1 ------------------ ISP 1 Router2 ----------- NSP 2 | | | | | | | annunce /21 | | | Customer1 --------------- ISP 1 Router1 announce /20
The "Customer1" is client on both ISPs (ISP1 and NSP1) and have an /20 IP prefix. To NSP1, it announce two /21 prefixes. To ISP1, it announce a /20 prefix. If traffic comes from NSP 2 (connected only to ISP 1) to Customer1, the ISP 1 Routers try to send data over NSP 1, ignoring the Custormer1->ISP1 link. To solve this question, an solution that I found is filter Customer1 prefixes in BGP session between NSP1 and ISP1 Router2. But this don't appear scalable...
longest match wins... if you're customer 1 deaggregate the avertisement to isp 1 or re-aggregate the advertisement to nsp 1. either will achieve the same end. if you're isp1 consider what customer 1 was trying to achieve by doing this. e.g. they're traffic engineering (or they are clueless) and theirfore have a vested interest in the current path.
Is this solution right ? What is the better solution for this scenario? How large ISPs solve this kind of problem?
Thanks,
Rafael
Dear Rafael,
Is this solution right ? What is the better solution for this scenario? How large ISPs solve this kind of problem?
communitie(filters) help to scale. for example lambdanet communities: remarks: Prepend communities to modify announcements to peers remarks: remarks: 13237:3811n announcements to AS12322 (Free) remarks: 13237:3812n announcements to AS3356 (Level3) remarks: 13237:3813n announcements to AS8220 (COLT) remarks: 13237:3814n announcements to AS286 (KPN Eurorings) remarks: 13237:3815n announcements to AS3303 (Swisscom) remarks: 13237:3818n announcements to AS9121 (TurkTelekom) remarks: 13237:3824n announcements to AS2914 (Verio) remarks: 13237:3825n announcements to AS4766 (Korea Telecom) remarks: 13237:3826n announcements to AS3491 (BtN) remarks: 13237:3828n announcements to AS8928 (Interoute) remarks: 13237:3830n announcements to AS1257 (Swipnet) remarks: 13237:3831n announcements to AS3292 (TeleDanmark) remarks: 13237:3832n announcements to AS3209 (Arcor) remarks: 13237:3833n announcements to AS3320 (DTAG) remarks: 13237:3835n announcements to AS6805 (Telefonica DE) remarks: 13237:3836n announcements to AS8447 (Telekom AT) remarks: 13237:3837n announcements to AS8881 (Versatel DE) remarks: 13237:3838n announcements to AS13184 (Hansenet) remarks: 13237:3855n announcements to AS6830 (Chello) remarks: 13237:3860n announcements to AS3257 (Tiscali Int.) remarks: 13237:3865n announcements to AS702 (MCI EU) remarks: 13237:3866n announcements to AS3549 (Global Crossing) remarks: 13237:3869n announcements to AS6453 (Tata/Teleglobe) remarks: 13237:3870n announcements to AS20676 (QSC) remarks: 13237:3876n announcements to AS2856 (BT UK) remarks: 13237:3877n announcements to AS2119 (Telenor) remarks: 13237:3891n announcements to AS1299 (TeliaSonera) remarks: 13237:3892n announcements to AS6461 (Abovenet) remarks: remarks: with n = 0,1,2,3 meaning remarks: n = 0 do not announce to peer remarks: n = 1 prepend "AS13237" remarks: n = 2 prepend "AS13237 AS13237" remarks: n = 3 prepend "AS13237 AS13237 AS13237" Kind regards, Ingo Flaschberger
participants (4)
-
Ingo Flaschberger -
joel jaeggli -
Michael K. Smith - Adhost -
Rafael Ganascim