Mailing List Archive: Cisco: NSP

Testing New BGP Provider

Index | Next | Previous | View Threaded

mitch at stonernetworks

May 4, 2012, 7:37 PM

Post #1 of 6 (533 views)
Permalink

Testing New BGP Provider

Whats the best way to go about testing a new service provider connection
with BGP on a production router? Should I put the new connection in a VRF
to receive the global routing table and make sure things work as expected?
Or do I simply filter all routes initially and slowly permit a few
individual routes to be sure things look correct? Router is an ASR9000. What
do others typically do?

Thanks!

_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

dcp at dcptech

May 4, 2012, 8:04 PM

Post #2 of 6 (504 views)
Permalink

Re: Testing New BGP Provider [In reply to]

Mitch,
I have never done this. But, my first thought is to set local preference to
1, forcing the learned routes to be the last used. Putting the routes into a
VRF on the ASR9000 is a non-starter unless running the latest code and you
can define the VRF as a BIG VRF, so I would stay away from that. In IOS "sh
ip bgp neighbors x.x.x.x" displays a lot of information about the neighbor,
not sure if the same for IOS-XR.

David

--
http://dcp.dcptech.com

-----Original Message-----
From: cisco-nsp-bounces [at] puck
[mailto:cisco-nsp-bounces [at] puck] On Behalf Of Mitch Stoner
Sent: Friday, May 04, 2012 10:38 PM
To: cisco-nsp [at] puck
Subject: [c-nsp] Testing New BGP Provider

Whats the best way to go about testing a new service provider connection
with BGP on a production router? Should I put the new connection in a VRF
to receive the global routing table and make sure things work as expected?
Or do I simply filter all routes initially and slowly permit a few
individual routes to be sure things look correct? Router is an ASR9000. What
do others typically do?

Thanks!

_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

jcoleman at centauricom

May 5, 2012, 2:44 PM

Post #3 of 6 (494 views)
Permalink

Re: Testing New BGP Provider [In reply to]

Hi, Mitch

I put an example for you how you could test a few carrier routes aka
Cogent AS 174 and XO AS 2828 for your reference. The AS 3356 put what your
upstream provider is that one listed is Level3. This would allow you to
send a few outbound tests but not the entire Internet as you mentioned on
your post. Once your happy then start advertising your IP Prefix and
remove the DENY_ALL_PFX and see how that performs for inbound. But overall
your best results if your worried is just take it slow.

neighbor x.x.x.x activate
neighbor x.x.x.x soft-reconfiguration inbound
neighbor x.x.x.x prefix-list DENY_ALL_PFX out
neighbor x.x.x.x route-map set-local-isp-testing in

ip as-path access-list 20 permit ^3356_174_
ip as-path access-list 20 permit ^3356_2828$

ip as-path access-list 21 deny .*

ip prefix-list DENY_ALL_PFX seq 100 deny 0.0.0.0/0

route-map set-local-isp-testing permit 10
match as-path 20
set local-preference 200
!
route-map set-local-isp-testing permit 20
match as-path 21
set local-preference 1

> Whats the best way to go about testing a new service provider connection
> with BGP on a production router? Should I put the new connection in a VRF
> to receive the global routing table and make sure things work as expected?
> Or do I simply filter all routes initially and slowly permit a few
> individual routes to be sure things look correct? Router is an ASR9000.
> What
> do others typically do?
>
> Thanks!
>
>
> _______________________________________________
> cisco-nsp mailing list cisco-nsp [at] puck
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>

Josh Coleman
Chief Architect
Work +1 415.294.2240 X1010

---
Centauri Communications
Light years ahead of the Internet.
http://www.centauricom.com

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

tom at snnap

May 6, 2012, 12:21 PM

Post #4 of 6 (483 views)
Permalink

Re: Testing New BGP Provider [In reply to]

Or how about AS32934 (aka Facebook).

If theres anything wrong with your new transit, you'll know about it
quick smart. :-)

On 5 May 2012 22:44, Josh Coleman <jcoleman [at] centauricom> wrote:
> Hi, Mitch
>
> I put an example for you how you could test a few carrier routes aka
> Cogent AS 174 and XO AS 2828 for your reference. The AS 3356 put what your
> upstream provider is that one listed is Level3. This would allow you to
> send a few outbound tests but not the entire Internet as you mentioned on
> your post. Once your happy then start advertising your IP Prefix and
> remove the DENY_ALL_PFX and see how that performs for inbound. But overall
> your best results if your worried is just take it slow.
>
> neighbor x.x.x.x activate
> neighbor x.x.x.x soft-reconfiguration inbound
> neighbor x.x.x.x prefix-list DENY_ALL_PFX out
> neighbor x.x.x.x route-map set-local-isp-testing in
>
> ip as-path access-list 20 permit ^3356_174_
> ip as-path access-list 20 permit ^3356_2828$
>
> ip as-path access-list 21 deny .*
>
> ip prefix-list DENY_ALL_PFX seq 100 deny 0.0.0.0/0
>
> route-map set-local-isp-testing permit 10
> match as-path 20
> set local-preference 200
> !
> route-map set-local-isp-testing permit 20
> match as-path 21
> set local-preference 1
>
>
>
>> Whats the best way to go about testing a new service provider connection
>> with BGP on a production router? Should I put the new connection in a VRF
>> to receive the global routing table and make sure things work as expected?
>> Or do I simply filter all routes initially and slowly permit a few
>> individual routes to be sure things look correct? Router is an ASR9000.
>> What
>> do others typically do?
>>
>> Thanks!
>>
>>
>> _______________________________________________
>> cisco-nsp mailing list cisco-nsp [at] puck
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
>> --
>> This message has been scanned for viruses and
>> dangerous content by MailScanner, and is
>> believed to be clean.
>>
>>
>
>
> Josh Coleman
> Chief Architect
> Work +1 415.294.2240 X1010
>
>
> ---
> Centauri Communications
> Light years ahead of the Internet.
> http://www.centauricom.com
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
> _______________________________________________
> cisco-nsp mailing list cisco-nsp [at] puck
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

jmaimon at ttec

May 6, 2012, 4:20 PM

Post #5 of 6 (479 views)
Permalink

Re: Testing New BGP Provider [In reply to]

Have them setup an additional multihop ebgp setup that you can funnel to
a disjoint route server so that you can examine what exactly is in their
full table.

Thats a good way to find the rfc1918 prefixes and customer routes and
more specific peer routes that really dont belong there.

Or even just use the multihop+connected session approach full time.

A provider willing to work with you is a cut above the rest, so now is a
good time to find out exactly how accommodating you can get them to be.

Push out only a /24 test prefix, have some test nodes running on that,
or even some "sacrificial lambs". Check and see that you can properly
withdraw the route, that it shows up (and disappears) as it is supposed to.

Use some policy to prefer some of what you are getting from them and see
how that goes.

Then normalize.

Joe

Mitch Stoner wrote:
> Whats the best way to go about testing a new service provider connection
> with BGP on a production router? Should I put the new connection in a VRF
> to receive the global routing table and make sure things work as expected?
> Or do I simply filter all routes initially and slowly permit a few
> individual routes to be sure things look correct? Router is an ASR9000. What
> do others typically do?
>
> Thanks!
>
>
> _______________________________________________
> cisco-nsp mailing list cisco-nsp [at] puck
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>
_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

petelists at templin

May 6, 2012, 8:12 PM

Post #6 of 6 (484 views)
Permalink

Re: Testing New BGP Provider [In reply to]

On 5/4/12 9:37 PM, Mitch Stoner wrote:
> Whats the best way to go about testing a new service provider connection
> with BGP on a production router? Should I put the new connection in a VRF
> to receive the global routing table and make sure things work as expected?
> Or do I simply filter all routes initially and slowly permit a few
> individual routes to be sure things look correct? Router is an ASR9000. What
> do others typically do?

Think forward: when things with provider X go to garbage, you want to be
able to detune that provider. If it happens at 3am, do you want to
think through the process of detuning them? I didn't think so. Make a
route-map (two, actually; one for inbound and one for outbound) that
puts the provider in maintenance mode. For inbound, drop local
preference below your normal and add some prepends. For outbound, set
community to request lower than normal local preference, and add some
prepends. Make a 'no-routes' while you're at it (deny everything in the
first line). Start the session with no-routes so you know it's
provisioned correctly, then switch to maintenance mode, then switch to
normal.

pt

_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads