I have noticed that when running multihop BGP, connected routes are not passed on. Perhaps I am not configuring it correctly?
I think this is one more reason to have the network command. Aside from that, our ISP doesn’t like the fact that we are announcing so many /28s and /29s now with the current setup. Fortunately they are taking care of everything for us while we get this upgrade completed, but we want to get it to where we are only announcing our /20 and that’s it.
PLEASE ADD BACK THE NETWORK COMMAND!!! (and add a null interface too!)
Post your config … it’s somewhat working here. I have major issues with more than 10,000 routes but that’s another story.
The outbound prefix filters on our system are filtering out routes we do not want to annouce. Are you saying that your telling it to filter but its still annoucing them? Again, post the config so we can help troubleshoot.
You can add a bridge interface with no members and call it null … this is what we’ve done to get around no loopback interface and it seems to work fine.
The router is picking up over 182000 routes and working just fine with them. We are going to get our Cogent link turned up shortly, but first this has to get done. The Cogent link worked fine on the old standard BGP package because it didn’t need BGP, but we are very dependent on our main link (Level3 and Internap combined the data center we are in). According to our ISP, we are handing them off tons of routes, when all they want from us is 63.249.32.0/20. Why, oh why, must it be this complicated? If I turn off multihop in a test situation it announces all connected and static routes, where with multihop it is static only. It also is handing off only the block of IPs I want it to have announced – none of the privates are being announced with the routing filter I have added.
I have found a solution for my problem that will work – I can add another router into the network, but I really don’t find it reasonable to spend another $500 on a router to put at the head-end of the network to do something that BGP on any other router does fine.
You should not use ‘action=discard’ if thats the route you are trying to announce. With that being the only rule you are dropping your one good block and annoucing all others : )
Change that action to accept, and then place another rule right below it with a discard for everything else.
Here is a sample of what I am doing that works perfectly.
In my testing, I had to use action=discard and use the invert-match on the outbound. Trying to phrase it correctly:
IF Prefix IS NOT EQUAL TO 63.249.32.0/20
THEN DISCARD
And then apply that to the outgoing filter. Does that clear up why I did it that way? In my test situation here, that did work correctly as long as I statically routed it.
Regarding the Cogent link, we are going through another provider for that which already terminates the connection for us with Cogent to make it simple. We wanted to keep everything weighted evenly, so it made plenty of sense (almost too much sense!) to go ahead with the partner agreement with another provider that already had a single Cogent link. That way it does already look like a Tier 2 provider. Also, I don’t want the incoming routes filtered, and I see that happening with the rule that you supplied - I want everything on this one to come in and end up in the routing table.
I hope it doesn’t sound like I am preaching because obviously you know a lot more about bGP than myself, but at the same time I want to understand why not to do the things that I did.
I think that invert-match is new in this release, I’ve never explored it … maybe its the source of the issue? I try to build the routing filters just like the firewall filters, allow what you need and discard the rest. I try to stay away from the ! rules except where necessary.
I’m still learning bgp too : ) I am not expert thats for sure!
I am guessing you are probably in the US. I would like to speak to you as you seem to be more knowledgable at this stuff than I am. Any way to call you?
In 2.9.18, filtering at the peer did not have any effect.
I cannot yet confirm if this has been fixed in 2.9.20, but you should still try changing your ‘peer’ based filter to an ‘instance’ filter and see what happens
