Book now with code EOY2025
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.
notgoing2fail wrote: » Hey Jason, I put this on the ISP router and it worked... neighbor x.x.x.x default-originate
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?
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.
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)
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.
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.
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?
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!
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.
jason_lunde wrote: » did you look for anything that started with " ip as-path access-list [#]" ?
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.
Use code EOY2025 to receive $250 off your 2025 certification boot camp!
