I've try to connecting with ISP Router using BGP.
if i used MT 2.8, ican succesfully connected. but i'd followed about manual to setting routing-test at 2.9.6 isn't success anymore.
can i give info for this problem?
[admin@MikroTik] > routing bgp instance print
Flags: X - disabled
0 as=2320 router-id=202.156.27.52 redistribute-static=no redistribute-connected=no redistribute-rip=no
redistribute-ospf=no redistribute-other-bgp=no name="default" out-filter=no
[admin@MikroTik] > routing bgp peer print
Flags: X - disabled
0 remote-address=202.12.23.19 remote-as=2320 multihop=no in-filter="" out-filter="" keepalive-time=0s hold-time=0s
ttl=1
this is log display :
03:01:49 route,bgp,info Failed to open TCP connection
03:01:49 route,bgp,info RemoteAddr=202.12.23.19
03:01:49 route,bgp,info RemotePort=179
03:02:49 route,bgp,info Failed to open TCP connection
03:02:49 route,bgp,info RemoteAddr=202.12.23.19
03:02:49 route,bgp,info RemotePort=179
Please Help me...
Thanks All
Pure
-
-
ucinggarong
just joined
- Posts: 2
- Joined:
Hello,
We use 2.9.6 for bgp currently.
In your peer make sure your remote-as is correct ... it is the same as your as number?
You can turn on more debug logging for bgp if you wish. System Logging - setup BGP topic.
I've seen this happen before yet the remote is connected. Check the status of each peer and see if its established. If you reboot and it goes away temporarily its the same issue. This reoccurs after the first disconnected peer ... doesn't cause problems though. Again this is in 2.9.6.
Make sure that your input chain is allowing port 179 from the peer. If you still need help post more details.
Sam
We use 2.9.6 for bgp currently.
In your peer make sure your remote-as is correct ... it is the same as your as number?
You can turn on more debug logging for bgp if you wish. System Logging - setup BGP topic.
I've seen this happen before yet the remote is connected. Check the status of each peer and see if its established. If you reboot and it goes away temporarily its the same issue. This reoccurs after the first disconnected peer ... doesn't cause problems though. Again this is in 2.9.6.
Make sure that your input chain is allowing port 179 from the peer. If you still need help post more details.
Sam
Please enlighten me on how exactly this is done on the routing-test package. I have spent hours tonight working on this and I cannot get it to show that a BGP session is even established. Not only that but on my lab setup I cannot get a multihop BGP session to work at all. Using routing-test I have no details, and on the standard routing package I do show that the status is connected and 1 route is being distributed, but that route is not showing up in the routing tables.Check the status of each peer and see if its established.
This is extremely frustrating, but hopefully knowing how to check this would help.
Thanks in advance.
routing-test does not have any winbox front end. You will need to use terminal mode.
/routing bgp peer print status
This will show each peer and its status. If it's not state=established then there is something not working.
Its helpful to turn on the debug logging (/system logging) for bgp and route topics. You will see tons of messages scroll by that help diagnose problems. I still think there are major problems with routing-test bgp implementation - mainly when using mikrotik to mikrotik as peers. Not sure why really ... connect it to a cisco and it seems to work fine.
Last night we troubleshot a friends bgp peering session for hours trying to figure out why we could not connect 2.9.12 to 2.9.12... session would open and then the bgp process seemed to just die over - tcp 179 was being rejected. Stop and start the peer and it would come back for a split second and then disappear again. I think there is something causing it to crash the process but there is no debug showing this. I wish there was a way to see the processes running to verify that. We pointed the peer to a cisco router and bam, it worked almost instantly.
I've done quite a bit with bgp in mikrotik over the past few months. If you post your '/routing export' config I will see if I can help you.
Sam
Sam
/routing bgp peer print status
This will show each peer and its status. If it's not state=established then there is something not working.
Its helpful to turn on the debug logging (/system logging) for bgp and route topics. You will see tons of messages scroll by that help diagnose problems. I still think there are major problems with routing-test bgp implementation - mainly when using mikrotik to mikrotik as peers. Not sure why really ... connect it to a cisco and it seems to work fine.
Last night we troubleshot a friends bgp peering session for hours trying to figure out why we could not connect 2.9.12 to 2.9.12... session would open and then the bgp process seemed to just die over - tcp 179 was being rejected. Stop and start the peer and it would come back for a split second and then disappear again. I think there is something causing it to crash the process but there is no debug showing this. I wish there was a way to see the processes running to verify that. We pointed the peer to a cisco router and bam, it worked almost instantly.
I've done quite a bit with bgp in mikrotik over the past few months. If you post your '/routing export' config I will see if I can help you.
Sam
Sam
I am just really getting frustrated with it. I put together a lab setup with 4 routers last night trying to prove my theory and it didn't work, and I keep trying to no avail. I have spent more time (money) on this than if I had just bought a Cisco to do the same functionality. Of course I will admit, I love Mikrotik, it's a great product, and it really functions much better than any other router that we have tried in our network to get this functionality out of.
Anyway, back to the point. I had the debug logging turned on and it was working well. I could see each BGP connection attempt with no issues. The lab setup was based on all Mikrotik RB532s as they were more readily available in my testing. I set this up initially with 5 routers, and once I discovered where the flaw was, I was able to make it work with 4 routers the same way. The biggest issue is that this is not a BS/testing/development issue -- this is a production issue. We need to get BGP working with this as we are capping out what our primary provider is handing to us, and they have much better bandwidth than our secondary Cogent (yuck!) link. Obviously with this in mind we want to have all of our traffic on the highest cost network just because it gets where it needs to go.
Now that I have made an even more garbled mess, here is my exact setup:
(RouterName) (ASN)
Internet 1000
BGPEDGE 2000
DIST N/A
CUST 3000
I have set up Internet and BGPEDGE to talk to each other, and they are passing routes. As can clearly be seen here, they are not multihop. However, BGPEDGE and CUST must link to each other. This is where the problem is coming into play. I am able to telnet from each router to each router on port 179 and I do achieve the connection. I am even able to see both routers trying to link to each other but they are not. The way I understand it in my lab setup, router DIST does not need to be set up for anything except static routes. This imitates exactly what is handed off to us by our premium bandwidth provider -- they have 2 incoming links from Tier 1 providers and they run into their BGP edge router, then they use a distribution router that everybody within the data center connects to, and then they hand it off to us from there. That way they have better management over what traffic is going through their systems.
So the problem that occurs is that the first routers link, but the second routers don't. Running the standard BGP I get it to link and it will show the routes, but then it says the destination is unknown in the routing tables. The routing-test package doesn't announce anything at all, from what I can tell, and it looks like it's not even creating the link.
Are you located in the US? Do you have any way to be contacted via IM, phone, etc? I would like to speak with you on your schedule and see what can be done to get this corrected, if possible.
Anyway, back to the point. I had the debug logging turned on and it was working well. I could see each BGP connection attempt with no issues. The lab setup was based on all Mikrotik RB532s as they were more readily available in my testing. I set this up initially with 5 routers, and once I discovered where the flaw was, I was able to make it work with 4 routers the same way. The biggest issue is that this is not a BS/testing/development issue -- this is a production issue. We need to get BGP working with this as we are capping out what our primary provider is handing to us, and they have much better bandwidth than our secondary Cogent (yuck!) link. Obviously with this in mind we want to have all of our traffic on the highest cost network just because it gets where it needs to go.
Now that I have made an even more garbled mess, here is my exact setup:
(RouterName) (ASN)
Internet 1000
BGPEDGE 2000
DIST N/A
CUST 3000
I have set up Internet and BGPEDGE to talk to each other, and they are passing routes. As can clearly be seen here, they are not multihop. However, BGPEDGE and CUST must link to each other. This is where the problem is coming into play. I am able to telnet from each router to each router on port 179 and I do achieve the connection. I am even able to see both routers trying to link to each other but they are not. The way I understand it in my lab setup, router DIST does not need to be set up for anything except static routes. This imitates exactly what is handed off to us by our premium bandwidth provider -- they have 2 incoming links from Tier 1 providers and they run into their BGP edge router, then they use a distribution router that everybody within the data center connects to, and then they hand it off to us from there. That way they have better management over what traffic is going through their systems.
So the problem that occurs is that the first routers link, but the second routers don't. Running the standard BGP I get it to link and it will show the routes, but then it says the destination is unknown in the routing tables. The routing-test package doesn't announce anything at all, from what I can tell, and it looks like it's not even creating the link.
Are you located in the US? Do you have any way to be contacted via IM, phone, etc? I would like to speak with you on your schedule and see what can be done to get this corrected, if possible.
Who is online
Users browsing this forum: bp0, Cavemansamurai and 26 guests