Community discussions

MikroTik App
 
faisali
Member Candidate
Member Candidate
Topic Author
Posts: 180
Joined: Fri Oct 08, 2010 5:11 am

BGP w/ Cogent

Tue Jul 26, 2011 12:21 am

Hello,

For those who have 'perfected' the BGP Peering setup with Cogent.... is there anything special (settings wise, target scope next hop etc) that you have found to be best ?

Other than the basic setup of Peer A, advertising routes, as well as the /32 loopback, and accepting the single /32 loopback from them.
And Peer B, not advertising anything, and accepting the Full BGP routing table via eBGP multi-hop from the router with the loopback address that was received via Peer A ?

Many Thanks in advance.
 
rpengineering
newbie
Posts: 38
Joined: Thu Mar 20, 2008 9:12 pm
Location: italy

Re: BGP w/ Cogent

Tue Jul 26, 2011 3:55 pm

Hello,

For those who have 'perfected' the BGP Peering setup with Cogent.... is there anything special (settings wise, target scope next hop etc) that you have found to be best ?

Other than the basic setup of Peer A, advertising routes, as well as the /32 loopback, and accepting the single /32 loopback from them.
And Peer B, not advertising anything, and accepting the Full BGP routing table via eBGP multi-hop from the router with the loopback address that was received via Peer A ?

Many Thanks in advance.
Dear,
i've multiple bgp session with cogent, what is the problem ..
 
faisali
Member Candidate
Member Candidate
Topic Author
Posts: 180
Joined: Fri Oct 08, 2010 5:11 am

Re: BGP w/ Cogent

Tue Jul 26, 2011 5:24 pm

No issue in particular, have seen some comments and posts about folks setting 'set-in-nexthop' on the bgp in filter and others commenting on using/ modifying target and scope to route received.

Was really looking for feedback as to what is the best practice setup with Cogent.

Thanks.
 
rpengineering
newbie
Posts: 38
Joined: Thu Mar 20, 2008 9:12 pm
Location: italy

Re: BGP w/ Cogent

Tue Jul 26, 2011 5:34 pm

No issue in particular, have seen some comments and posts about folks setting 'set-in-nexthop' on the bgp in filter and others commenting on using/ modifying target and scope to route received.

Was really looking for feedback as to what is the best practice setup with Cogent.

Thanks.
Dear,
I'm in single Hop with cogent, with i use only the filters for security..
on chain bgp-out an bgp-in to allow my prefix advertise, but to discard the advertise of the full-route by me ecc...
 
matthew
just joined
Posts: 10
Joined: Sat Sep 22, 2007 12:43 am
Location: Minneapolis, MN

Re: BGP w/ Cogent

Fri Jul 29, 2011 4:12 am

I'll be turning up both full IPv4 and IPv6 sessions on an RB1100 with Cogent next week. If it goes well, I'll post the finished configs here for ya.
 
changeip
Forum Guru
Forum Guru
Posts: 3819
Joined: Fri May 28, 2004 5:22 pm

Re: BGP w/ Cogent

Fri Jul 29, 2011 7:03 am

http://forum.mikrotik.com/viewtopic.php?p=21651#p21651

if your doing ipv6 now they most likely wont do the a & b configs ... thats old school : )
Colo and Wholesale Bandwidth Available! Sales at SanDiegoBroadband dot com
 
faisali
Member Candidate
Member Candidate
Topic Author
Posts: 180
Joined: Fri Oct 08, 2010 5:11 am

Re: BGP w/ Cogent

Fri Jul 29, 2011 5:40 pm

Here is what we did to get the peering going:-

Recipe for Cogent Peering (A & B) IPV4 on a Mikrotik Router.

First:-
add a loopback bridge you can name it what you like, we did 'cogent-loopback' assign it the /32 IP address as provided by Cogent
add another loopback for your own router ID, and assign it a ip address from your own prefix range (/32)

Second:
Add your Network Prefix as well as the /32 for the loop back to be advertised.
/routing bgp network 
 38.127.xx.0/yy      no
 38.xx.xx.169/32     no
Third:- (add your filters and bgp config).

Add the default instance,
name="default" as=40xxx router-id=(your selected Router Loopback iP) redistribute-connected=no redistribute-static=no redistribute-rip=no redistribute-ospf=no redistribute-other-bgp=no out-filter=hiq-redistribute client-to-client-reflection=no ignore-as-path-len=no routing-table=""
<<<<<<<<<<<<<<<<<You can change redistribute connected / redistribute static as needed, we are using an out filter to control that).>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Add the two Peers for Cogent, Peer A is for sending out the routes, and only recieving a single /32, which Peer B is going to use for Recieving Routes.
Remote Address of Peer B is the /32 sent back from Cogent. (loopback address on the router sending the full table on Cogent Side).
/routing bgp peer
name="COG-MIA1" instance=default remote-address=38.122.xx.5 remote-as=174 tcp-md5-key="" nexthop-choice=default multihop=no route-reflect=no hold-time=3m ttl=default
     in-filter=cog-in out-filter=cog-out address-families=ip update-source=cogent-loopback default-originate=never remove-private-as=yes as-override=no passive=no use-bfd=no

name="COG-MIA2" instance=default remote-address=38.xx.xx.168 remote-as=174 tcp-md5-key="" nexthop-choice=force-self multihop=yes route-reflect=no hold-time=3m ttl=default
     in-filter=cog-in out-filter=cog-b-out address-families=ip update-source=cogent-loopback default-originate=never remove-private-as=yes as-override=no passive=no use-bfd=no
Since we are using filters and setting some bgp communities, here is our filters that go with the above config.
chain=cog-in match-chain=junk invert-match=no action=discard
chain=cog-in prefix=38.xx.66.168 invert-match=no action=accept
chain=cog-in match-chain=not-to-specific invert-match=no action=accept set-in-nexthop=38.122.xx.5 set-bgp-prepend=1 append-bgp-communities=40xxx:666
<<<<< the specific prefixes are defined in the chains being referenced, since we have a bunch, and we re-use them, but you can simplify the config, by specifying prefix in the filter rather than making a reference to another chain. Additionally we are changing the default gateway of incoming bgp table to the outgoing interface of the connected router>>>>>>>>>>>>
chain=cog-out prefix=38.xx.xx.169 invert-match=no action=accept
chain=cog-out match-chain=HQD-40xxx invert-match=no action=accept
chain=cog-out match-chain=SDF-11xxx invert-match=no action=accept
chain=cog-out match-chain=SDG-10xxx invert-match=no action=accept
chain=cog-out bgp-communities=4xxxx4:115 invert-match=no action=accept
chain=cog-out invert-match=no action=discard
<<<<< (above) is how we are advertising routes>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
chain=cog-b-out invert-match=no action=discard
<<<<<<<<<<< this is to make sure we don't sent the routing table out again on Peer B>>>>>>>>>>>>>>>>>>>>>>

Open to suggestion and comments for improvements..

Thanks.
 
sten
Forum Veteran
Forum Veteran
Posts: 920
Joined: Tue Jun 01, 2004 12:10 pm

Re: BGP w/ Cogent

Mon Sep 26, 2011 12:05 am

Why are you using loopbacks for eBGP between providers (loopbacks are typically used in iBGP configuration)?

On a basic older Xeon x86 box i can receive the entire internet routing table x2 in matter of seconds (5 - 15 or so for both to be fully resolved and loaded). One of those are from Cogent. Are you getting a different result?
Move along. Nothing to see here.
 
SwissWISP
Member Candidate
Member Candidate
Posts: 181
Joined: Fri Sep 23, 2011 12:16 pm

Re: BGP w/ Cogent

Thu Sep 29, 2011 4:51 pm

Why are you using loopbacks for eBGP between providers (loopbacks are typically used in iBGP configuration)?
+1
That doesn't make much sense.
It only makes sense when you're using an IGP to manage multiple links between the routers which would cause the source IP to change when the main link goes down. But in your scenario, the source IP doesn't change.

Just my 2ct.
- Mat
 
mhosts
newbie
Posts: 36
Joined: Tue Nov 03, 2009 4:43 pm

Re: BGP w/ Cogent

Fri Sep 30, 2011 1:48 am

Why are you using loopbacks for eBGP between providers (loopbacks are typically used in iBGP configuration)?
+1
That doesn't make much sense.
It only makes sense when you're using an IGP to manage multiple links between the routers which would cause the source IP to change when the main link goes down. But in your scenario, the source IP doesn't change.

Just my 2ct.
- Mat
Cogent forces you to do this because they have 2 peers to setup BGP.

The first peer is the one you send your routes to. This peer send you one single route back, which is the loopback IP of the 2nd peer.

You then make a separate peering connection to this 2nd peer on a loopback IP (they assign you a /31) and this second peer is the one that sends you the routes.

It's slightly different than an IBGP config.
 
SwissWISP
Member Candidate
Member Candidate
Posts: 181
Joined: Fri Sep 23, 2011 12:16 pm

Re: BGP w/ Cogent

Fri Sep 30, 2011 9:34 am

It looks like a very uncommon setup. To me it still doesn't make much sense. But I don't know their network. :D

Anyway, thank you mhosts for the clarification.
 
changeip
Forum Guru
Forum Guru
Posts: 3819
Joined: Fri May 28, 2004 5:22 pm

Re: BGP w/ Cogent

Fri Sep 30, 2011 7:08 pm

It looks like a very uncommon setup. To me it still doesn't make much sense. But I don't know their network. :D

Anyway, thank you mhosts for the clarification.
they do it this way to prevent certain problems with flapping, etc. It prevents one bgp peer from coming up until the other is already stable. it is also so you can peer with their big router for downloading prefixes but peer with the local router for sending your annoucements.

if you ask for ipv6 on your port then they go back to the standard single bgp peer config which is easier in the long run...
Colo and Wholesale Bandwidth Available! Sales at SanDiegoBroadband dot com
 
mhosts
newbie
Posts: 36
Joined: Tue Nov 03, 2009 4:43 pm

Re: BGP w/ Cogent

Fri Sep 30, 2011 9:13 pm

Since they are in so many buildings, it also allows them to only run full BGP routing on certain key locations.

Most of their access switches aren't carrier routers, but rather BGP enabled switches that bring the routes back to the core.

The second peer is a "Multihop" peer. In some cases it can be a few hops away. Which is most likely linking back to a major core of the network.

There's no sense running big routers in some data centers where they only have one path out anyways.

Plus this method was probably established a very long time ago when there was more link bonding. So if one of your interfaces goes down, you're still up with your 2nd peer regardless.

Who is online

Users browsing this forum: No registered users and 11 guests