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:
- Location: italy
Re: BGP w/ Cogent
Dear,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.
i've multiple bgp session with cogent, what is the problem ..
Re: BGP w/ Cogent
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.
Was really looking for feedback as to what is the best practice setup with Cogent.
Thanks.
-
-
rpengineering
newbie
- Posts: 38
- Joined:
- Location: italy
Re: BGP w/ Cogent
Dear,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.
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...
Re: BGP w/ Cogent
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.
Re: BGP w/ Cogent
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 : )
if your doing ipv6 now they most likely wont do the a & b configs ... thats old school : )
Re: BGP w/ Cogent
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.
Third:- (add your filters and bgp config).
Add the default instance,
<<<<<<<<<<<<<<<<<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).
Since we are using filters and setting some bgp communities, here is our filters that go with the above config.
<<<<< 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>>>>>>>>>>>>
<<<<< (above) is how we are advertising routes>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
<<<<<<<<<<< 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.
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.
Code: Select all
/routing bgp network
38.127.xx.0/yy no
38.xx.xx.169/32 noAdd the default instance,
Code: Select all
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=""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).
Code: Select all
/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=noCode: Select all
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:666Code: Select all
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=discardCode: Select all
chain=cog-b-out invert-match=no action=discardOpen to suggestion and comments for improvements..
Thanks.
Re: BGP w/ Cogent
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?
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?
Re: BGP w/ Cogent
+1Why are you using loopbacks for eBGP between providers (loopbacks are typically used in iBGP configuration)?
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
Re: BGP w/ Cogent
Cogent forces you to do this because they have 2 peers to setup BGP.+1Why are you using loopbacks for eBGP between providers (loopbacks are typically used in iBGP configuration)?
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
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.
Re: BGP w/ Cogent
It looks like a very uncommon setup. To me it still doesn't make much sense. But I don't know their network. 
Anyway, thank you mhosts for the clarification.
Anyway, thank you mhosts for the clarification.
Re: BGP w/ Cogent
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.It looks like a very uncommon setup. To me it still doesn't make much sense. But I don't know their network.
Anyway, thank you mhosts for the clarification.
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...
Re: BGP w/ Cogent
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.
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.