BGP network missing mask

notgoing2fail

jason_lunde wrote: »

They are probably sending you the default...if thats what your getting at. There are numerous ways to do this in bgp...just for example

ip route 0.0.0.0 0.0.0.0 null0

ip prefix-list NULL permit 0.0.0.0/0

route-map THROWDEFAULT permit 10
match ip address prefix NULL

router bgp [as]
neighbor x.x.x.x route-map THROWDEFAULT out

This will hand that neighbor the default and nothing else. Like I mentioned...there are a couple other ways to do this. Depends on who configured it, and what routes they want to hand off. Also, both routers can advertise the same route; again depend on your situation and whoever designed the network. As other have said, this is not an IGP. The basis around BGP is that YOU dicatate your routing policys. Noone else can dictate how another AS routes their traffic...they can make suggestions, but you dont have to listen to them. Hope this helps man.

It sure does, thanks Jason...

I'm just going to use one of those commands above from the ISP side to push the default route to my edge router. As long as I can get the default route into the BGP that's fine with me so I can ping out from my AS....

Your advice here as well as others are very much appreciated I hope I can return the favor at some point!!

notgoing2fail

Hey Jason,

I put this on the ISP router and it worked...


neighbor x.x.x.x default-originate

jason_lunde

notgoing2fail wrote: »

Hey Jason,

I put this on the ISP router and it worked...


neighbor x.x.x.x default-originate

Yep, like I said...there are many ways to kill that bird.

Forsaken_GA

notgoing2fail wrote: »

Would there be any risk of having both edge routers advertise a specific internal network? Obviously the routing would be different on each router, but I'm wondering if it would cause any kind of looping issues?

Generally, no, but it all depends on how you're advertising it, and who you're advertising it to. Two routers can advertise the same network though, and that generally won't cause an issue. You should review the criteria BGP uses for path selection.

Now, with that being said - when it comes to annoucing external IP's, announcing routes which don't belong to you without the express permission of the people who do own it (ie, you're a service provider, and you have a customer who has their own IP allocation, but doesn't want to run BGP with you to announce their own space, they just want you to give them a default route) is a good way to get depeered. Network operators do not look kindly upon prefix hijacking, or peers who have been accidentally misconfigured. The ones that are on top of their game will use prefix-lists to prevent them from accepting any new routes from you until you talk to them in an effort to save you from yourself.

And never never never never announce RFC 1918 space over a globally routable peering connection. A good peer won't accept them, but it's better to make sure both sides of the link are filtering private IP space. BGP done right includes extensive use of route-maps and filters.

And I strongly recommend taking a look at BCP 84. While not strictly BGP related, anyone who's announcing global routes should do their best to be a good neighbor and do what they can to prevent IP spoofing.

notgoing2fail

Forsaken_GA wrote: »

Generally, no, but it all depends on how you're advertising it, and who you're advertising it to. Two routers can advertise the same network though, and that generally won't cause an issue. You should review the criteria BGP uses for path selection.

Now, with that being said - when it comes to annoucing external IP's, announcing routes which don't belong to you without the express permission of the people who do own it (ie, you're a service provider, and you have a customer who has their own IP allocation, but doesn't want to run BGP with you to announce their own space, they just want you to give them a default route) is a good way to get depeered. Network operators do not look kindly upon prefix hijacking, or peers who have been accidentally misconfigured. The ones that are on top of their game will use prefix-lists to prevent them from accepting any new routes from you until you talk to them in an effort to save you from yourself.

And never never never never announce RFC 1918 space over a globally routable peering connection. A good peer won't accept them, but it's better to make sure both sides of the link are filtering private IP space. BGP done right includes extensive use of route-maps and filters.

And I strongly recommend taking a look at BCP 84. While not strictly BGP related, anyone who's announcing global routes should do their best to be a good neighbor and do what they can to prevent IP spoofing.

You really hit the money on this last post. I've been learning so much about BGP the last couple of days thanks to everyone here. I suppose the best way to learn something is to really dive into it.

But in this case, I am using GNS to simulate the setup so that I don't totally screw up production which would end my career. LOL!!!


We do have route-maps/filters in place, they are pretty basic, basically using regex to only allow our AS out. Which means that I need to do some more investigation because we have 3 clients right now with their own AS and I am unsure of what our agreements are as far as what you mentioned here:

when it comes to annoucing external IP's, announcing routes which don't belong to you without the express permission of the people who do own it (ie, you're a service provider, and you have a customer who has their own IP allocation, but doesn't want to run BGP with you to announce their own space, they just want you to give them a default route)

I'm also unsure of how they are even able to get out because I think the route map has filters on them for just our AS!! So this is interesting.....

notgoing2fail

Hey guys, I'm just about done with my BGP simulation. Everything is working pretty well.

I have one issue that I'm unsure of and why it's behaving this way.

I have a fully meshed iBGP between 3 routers. R1, R2 and R3

Hanging off R3 is another router(R3-A) and that is eBGP. Everything works well.

Hanging off R1 is another router (R1-A) and that is also eBGP.

This is where I'm seeing a strange issue.

R1-A is displaying a "2" in PFX/RCD when it comes to the BGP status when I do this: SH IP BGP SUMMARY

On R1, I am seeing "0" for the status. I am unable to get R1-A to announce it's network to everyone else. It just won't do it?

The connection between the two routers is "established" which is why it doesn't make any sense?


Does anyone know why R1-A has status of 2, connecting to R1 with status of 0?

For all the other routers where the BGP is working, the status displays "1".

Forsaken_GA

ok, the first thing you need to know is that PFX/RCD stands for Prefixes Received. It's not a status code. The one that says 2 simply means it has received 2 prefixes (routes). 0 means it hasn't received any. If there's a number there, it means the BGP session is up and running (otherwise it would say Active, Idle, etc)

Does R1A have the routes it's trying to announce in it's routing table? ie, have you configured static routes, or have they been learned from another IGP. That's the most common reason for a network not announcing. Otherwise, your network commands might be screwed up. You could also be doing some filtering on the other end, so that the router is actually sending them, but the other side isn't accepting them.

If this is just a lab configuration with no operational details in the configs, post the configs for the two routers in question.

If worse comes to worse, turn on some debugging and then clear ip bgp * to bounce the BGP session and watch the exchange for hints.

notgoing2fail

Forsaken_GA wrote: »

ok, the first thing you need to know is that PFX/RCD stands for Prefixes Received. It's not a status code. The one that says 2 simply means it has received 2 prefixes (routes). 0 means it hasn't received any. If there's a number there, it means the BGP session is up and running (otherwise it would say Active, Idle, etc)

Does R1A have the routes it's trying to announce in it's routing table? ie, have you configured static routes, or have they been learned from another IGP. That's the most common reason for a network not announcing. Otherwise, your network commands might be screwed up. You could also be doing some filtering on the other end, so that the router is actually sending them, but the other side isn't accepting them.

If this is just a lab configuration with no operational details in the configs, post the configs for the two routers in question.

If worse comes to worse, turn on some debugging and then clear ip bgp * to bounce the BGP session and watch the exchange for hints.

oh interesting.....sorry for the confusion....ok so it is prefixes received and not status code....got it....

It is simulation based on production, but I can easily replace anything that production (aka: AS numbers) and post the config. I will do this tomorrow since I don't have access to the GNS server right now from home.

To answer your question, there is no IGP running, all static routes. I am able to ping the other router R3-A from R1-A so that's why I had assume that routing wise, nothing was wrong but maybe I'm still off...

I will provide some more info tomorrow as well as a diagram to make it a little easier....thanks very much I think we are close to figuring this out and wrapping up my first time BGP project!!!!!

networker050184

I think its about time to pause on the lab and get to reading. You need to get the basics of the commands and output down if you ever want to understand whats going on with your routers.

notgoing2fail

networker050184 wrote: »

I think its about time to pause on the lab and get to reading. You need to get the basics of the commands and output down if you ever want to understand whats going on with your routers.

No I understand, I am a fundamentals guy, I always like to read and understand 101 before I do things. I'm trying to multi-task right now as you can see.....although it's not super super important, but my company is looking for me to try to resolve this issue....and with other projects I have to work on, unrelated to Cisco, I have to get this out of the way...


In any event, I have figured out my issue, DUH on my part!!

What happened was that I was using CIDR addressing. It was a class C address but with a /22.

So in my mask for the ip address of the interface, I was using 255.255.255.252 instead of 255.255.252.0

Now that I've updated it, it works!!!


I'm going to work in the finishing touches but I really thank you all for your assistance.

If you think I am going to abandon BGP after this project, nope! I will be catching up on the reading and I'll probably go into BGP certification mode. I might as well go for the cert now while it's fresh in my head. Might take me 2 months but let's get it out of the way....

notgoing2fail

Ok here's another question....

Riddle me this....

(R1) ---iBGP--- (R2) ---eBGP--- (R3)


R1 is seeing the network from R3 coming from R2.

When I do a "sh ip bgp neighbor x.x.x.x(R2) received-routes" on R1, I am seeing the network from R3.

But the network isn't being injected into the BGP table in R1. There are no fancy access-list on R1. It's just simply not going in...

would issuing: debug ip bgp help look into the problem? I'm a little concerned about doing that command on production equipment....

Thoughts?

jason_lunde

notgoing2fail wrote: »

Ok here's another question....

Riddle me this....

(R1) ---iBGP--- (R2) ---eBGP--- (R3)


R1 is seeing the network from R3 coming from R2.

When I do a "sh ip bgp neighbor x.x.x.x(R2) received-routes" on R1, I am seeing the network from R3.

But the network isn't being injected into the BGP table in R1. There are no fancy access-list on R1. It's just simply not going in...

would issuing: debug ip bgp help look into the problem? I'm a little concerned about doing that command on production equipment....

Thoughts?

Go read your books man no but really, it is an ebgp route from an ibgp neighbor, so the next hop is probably unchanged (unless you changed it on R2). ITs the first check, if R1 does not have reachability to the subnet between R2--R3 then the route will not be installed. So first things first...see if R1 knows about that subnet between R2 and 3.

jason_lunde

BGP Best Path Selection Algorithm [IP Routing] - Cisco Systems

check it out man...look at the section why routers ignore paths.

Ryan82

Look for information on the next-hop-self command.

deth1k

Do sh ip bgp rib, which will tell you why the route isn't in there or do sh ip bgp ip_address mask and it will tell you in the output if the next hop is unreachable.

Forsaken_GA

This is probably one of the biggest trip ups for BGP beginners.

As I said earlier in the thread, if BGP does not have a valid route to the next hop address in the advertised route, it will not install the route.

R2 should be setting a neighbor command for R1 for next-hop-self. This basically says that R2 is going to modify the route advertisements to set itself as the next hop, and then send the route to R1. BGP does not automatically propagate it's own links, so you'd need to advertise the R2-R3 link into the IGP, advertise it with a network command in BGP, or set a static route on R1 that points the next hop for that link to R2. All three of those will give R1 a route in it's table for the next hop to R3, but all of those have other consequences.

So the easy solution is to avoid all that and just have the eBGP routers set themselves as the next hop before advertising the routes internally. That's one less route you need to propagate throughout your AS, and much less administrative overhead

notgoing2fail

Thank you gentlemen!

I actually figured it out, you will go nuts. It was a filter list that was created on R1. I had missed that. When I took it out, it was able to accept the network advertisement.




This pretty much completes my BGP project now. Which means I can now go back and fully read and understand the basic principles of BGP. I'm going to look forward to taking the BGP certification now.

I'm going to strike while the iron is hot and BGP has my interests!

jason_lunde

notgoing2fail wrote: »

Thank you gentlemen!

I actually figured it out, you will go nuts. It was a filter list that was created on R1. I had missed that. When I took it out, it was able to accept the network advertisement.




This pretty much completes my BGP project now. Which means I can now go back and fully read and understand the basic principles of BGP. I'm going to look forward to taking the BGP certification now.

I'm going to strike while the iron is hot and BGP has my interests!

just for S&G's what was the filter list? It usually signifies filtering something by AS-path which has usually been put in for some pretty good reasons. So, it just peeks a bit of interest.

notgoing2fail

jason_lunde wrote: »

just for S&G's what was the filter list? It usually signifies filtering something by AS-path which has usually been put in for some pretty good reasons. So, it just peeks a bit of interest.

Good question. The filter list went nowhere. It was referring to an access-list that didn't exist.

You see, I was taking production configuration and simulating it via GNS. So it was like for like.....

It was just an old filter list that had no description, and again, referred to a non-existing ACL.

My assumption is that eventhough the ACL didn't exist, it must have been a default behavior to issue an "implicit deny" anyways.

So removing it, also removed that suspect "implicit deny"....

jason_lunde

did you look for anything that started with " ip as-path access-list [#]" ?

notgoing2fail

jason_lunde wrote: »

did you look for anything that started with " ip as-path access-list [#]" ?

Yes, we have a couple of those, they didn't interfere with the simulator. I had them in my simulator as well.

It was this PIA filter-list that was referring to an access-list 2, and it was applied inbound!

When I removed it, the BGP route went into the BGP table. I just went ahead and added it in again, and it blocked it again.

So I guess I've learned something new, in that, if you refer to a non-existing ACL, then by default, the router will treat it as existing and apply an implicit deny action....

jason_lunde

I guess what I want to make clear is this. I am thinking you saw a command like so:
router bgp [x]
neighbor x.x.x.x filter-list 2 in

Is that correct?
If so, this ties to a statement somewhere in your config that starts:
ip as-path access-list 2 [regex]

I am just making sure that you understand this, and am hoping you were not simply thinking that this ties to a standard access-list somewhere.

notgoing2fail

jason_lunde wrote: »

I guess what I want to make clear is this. I am thinking you saw a command like so:
router bgp [x]
neighbor x.x.x.x filter-list 2 in

Is that correct?
If so, this ties to a statement somewhere in your config that starts:
ip as-path access-list 2 [regex]

I am just making sure that you understand this, and am hoping you were not simply thinking that this ties to a standard access-list somewhere.

Absolutely correct.

We only have four "ip as-path access-list [n]"

They are 3,4,5,6

Somewhere along the lines, 1 and 2 must have disappeared and taken out. I don't know what they were suppose to do.

But there are no ip as-path access-list [1,2] anywhere in the config.....