Hi Laz, Thanks. So when the traffic comes for a destination IP of 147.52.3.15, it will first do NATting before route the packet to internal private subnet(10.X.X.X) ?
Hello Kuldeep
Yes, that is correct. The packet will be NATted before being routed. This is also standard for the NAT order of operations that are always very useful to review. Here is a link that describes these order of operations:
The case that you are describing is an outside-to-inside transaction.
I hope this has been helpful!
Laz
“When we use the network command in BGP then BGP will only look at the routing table. When it finds the network that matches the network command, it will install it in the BGP table.” Would this mean the loopback 1.1.1.0 from R1, that’s advertised to R2 via BGP won’t be installed on the R2 BGP table unless there’s a route to the loopback in the R2 routing table as well? I am still having issues understanding the relationship between the BGP table and the routing table. Any additional clarification will be very helpful.
Hello Thierno
This “rule” is relevant only when using the network command. Whenever you use the network command, the network that you are referring to in that command must be in the routing table in order for it to be installed in the BGP table and advertised.
Any network that a router learns about from a BGP neighbor will be placed in the BGP table and will not go through the routing table check.
So in the case of this lesson, R1 will place the 1.1.1.0/24 subnet in its routing table because the following two are true:
- it has been added using the network command
- it exists in the routing table because it is a directly connected network
R2 on the other hand will have the 1.1.1.0/24 network installed in its BGP and subsequently, routing table (if it is indeed the best route) because it was learned via BGP. There is no prerequisite for the route to be in the routing table in this case.
I hope this has been helpful!
Laz
Hello, Id like to clarify something that was actually mentioned but I did not quite get. This is one specific case of advertising default route. So I have a router (rather redundant pair) that are in the middle of the network. They have and advertise through BGP multiple internal networks. But they dont have default gateway. Now I have connected another pair of routers to them (typical crossbar configuration). I dont want to dump to them the whole BGP from my core. But still want to use BGP. Obviously, advertising only DG from core is 1st thing that comes to mind. So I thought there are 3 choices:
- On core routers create and advertise to new routers the new static route to 0.0.0.0 for Null0 interface. That did not look very elegant. Seems would work (since more specific routes still would be in the RIB and rest would go to Null) but still… So did not try that.
- Use with ‘neighbor’ statement the ‘default-originate’ switch. In my case core routers are ASRs, so this goes under address-family section. Tried and it worked fine - downstream routers show up now 0.0.0.0 route pointing to core. Packets will go there and then will be routed based on RIB there.
- Then I thought, why not to do the same for all other connected to core routers? But too many statements need to be reconfigured. So I discarded ‘default-originate’ in neighbor statement and instead added under global section of BGP config the ‘default-information originate’ statement. And, no result. Downstream routers dont have 0.0.0.0 network anymore.
So now Im confused - my understanding was that ‘default-information originate’ allows router to advertise default gateway to all the neighbors when actual default route does not exist in RIB. Same as ‘default-originate’ in the neighbor statement but ‘globally’ for all the neighbors. Is it not the case? It was mentioned earlier that defulat-information originate works only with redistribution. But if we redistribute default gateway it will anyway get advertised (unless we filter it out on purpose). Then why would we need default -information originate? It would be similar to my option ‘1’ above where I create route to null0 and then redistribute it into BGP. No need for anything else.
So can we clarify the purpose and application of the ‘default-information originate’ command? Maybe with some examples?
Hello Vadim
There are four ways to distribute a default route in BGP. The first three have a similar effect, two of which you have already described in your post:
network 0.0.0.0default-information originate- redistribution from another protocol
The fourth is the network X.X.X.X default-originate command which works a little differently. It is the same as the default-information originate command, because the default route doesn’t actually have to be in the routing table. However, it is different in that the default route will ONLY be advertised to this specific BGP neighbor and not to all BGP neighbors. The default route will NOTbe installed in the BGP RIB of the router on which you apply this command, so it won’t generally be advertised to all BGP neighbors.
Now the default-information originate command actually DOES place the default route into the RIB so that it does propagate it to all BGP neighbors. It is the network X.X.X.X default-information originate command that allows you to advertise a default route that is NOT in the routing table and is not placed within the RIB, and is sent ONLY to the specified neighbor.
I don’t know the details of your specific topology, but I hope this clarification will bring you a step closer to resolving your issue.
I hope this has been helpful!
Laz
Thanks, Lazaros, I still was having difficulties understanding the actual application and differences between all these commands. And I have to assume what you really meant in your explanation is not “It is the network X.X.X.X default-information originate command” (no such command exists) but rather “It is the neighbor X.X.X.X default-originate command”, which is quite different particularly when person is already quite confused. But it jolted my brain sufficiently enough that its finally dawned on me. Googling this thing was just getting the repetition of the same thing without anybody stating it in clear way (talking about technicians not good at communicating their thoughts :-)) . The ‘default-information originate’ command DOES NOT REQUIRE REDISTRIBUTION to work. That would be meaningless. IT IS redistribution. Thats if there are other protocols that are NOT redistributing into BGP but that do have default gateway then this command WILL then redistribute the DG (and only DG) into BGP, install it into BGP RIB and consequently advertise to all BGP neighbors. Also clear now why it did not work in my case while neighbor default-originate did. Actually, it did work in a sense - it was honestly ‘redistributing’ DG from any other RIB, its just that those did not have DG so nothing really was happening and no errors either. If at any time I would for instance add static route to DG it would immediately appear in BGP, as well (without me redistributing static). Thats all there is. Now all is very clear and purpose and function of each of these commands make complete sense. Thanks.
Hello Vadim
Yes, you are correct, and my apologies for that error 
.
I’m glad you’ve cleared it up and it is now fully understood!
Laz
I have yet another question regarding redistribution. Lets say I have a router with many interfaces and a sufficiently large block of static routes. So I want to advertise them by BGP. The ‘redistribution’ command would be a savior in this case- I just ‘redistribute’ static and connected into BGP. However, with many neighbors I dont want to advertise all the static and/or connected routes to all the neighbors, only to some. But the problem is the ‘redistribute’ command is a global command, it does not exist under each neighbor section. So how would I ‘redistribute’ only to selected neighbors? Is it even possible?
Hi Vadim,
In this case, you could use the redistribute command to get the static routes in your local BGP table and then use route-maps to define what you want to advertise to your neighbors. For example:
R1(config)#interface loopback 0
R1(config-if)#ip address 192.168.0.1 255.255.255.255
R1(config)#interface loopback 1
R1(config-if)#ip address 192.168.1.1 255.255.255.255
R1(config)#router bgp 1
R1(config-router)#redistribute connected R2 now sees both entries:
R2#show ip bgp
BGP table version is 8, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 192.168.0.1/32 192.168.12.1 0 0 1 ?
*> 192.168.1.1/32 192.168.12.1 0 0 1 ?Let’s get rid of one:
R1(config)#ip access-list sta R1_L0
R1(config-std-nacl)#permit host 192.168.0.1
R1(config)#route-map R2 permit 10
R1(config-route-map)#match ip address R1_L0
R1(config)#router bgp 1
R1(config-router)#neighbor 192.168.12.2 route-map R2 outR2 only sees the route we permit not:
R2#show ip bgp
Network Next Hop Metric LocPrf Weight Path
*> 192.168.0.1/32 192.168.12.1 0 0 1 ?Hope this helps!
Rene
1 Like
Ok, thanks Rene, thats kind of what I was thinking. So I would potentially end up with multiple route-maps for different neighbors to filter out undesirable routes for specific neighbors while by default redistributed routes would all get advertised to all neighbors. Actually, the question came from attempt to move configuration from Juniper to CISCO. In Juniper its another way around - by default nothing is advertised, need to have a policy indicating what neighbors the routes are redistributed to. Certainly better in this scenario. Just another proof no vendor is better or worse than another - shortcoming in one’s product is the strong feature in competitor’s. 
Hi, I have a question about the BGP network command.
In the article you state this:
When we use the network command in BGP then BGP will only look at the routing table. When it finds the network that matches the network command, it will install it in the BGP table.
So if, for example, the router learns about a network via EIGRP and installs it in its routing table, can that network be advertised directly into BGP with the network command, without redistributing EIGRP into BGP?
Thanks for any help 
Hello Jeremy
Yes, that is exactly correct. BGP can advertise networks using either the network command as described, or using redistribution.
I hope this has been helpful!
Laz
Thank you, Laz, that answers my question perfectly.
1 Like
Hi,
Ospf add entry from ospf database to routing table .
But bgp add from routing table to bgp table
Why it is like that
Thanks
Hello Sims
This is one of the fundamental differences between IGPs and BGP. To put it more clearly, OSPF will choose the best route to a particular destination found in its database into the routing table.
BGP on the other hand works a little differently. In order for a network to be installed in the BGP table, as it says in the lesson, it must be either installed using the network command or redistributed from another routing protocol. Now as you mention, in the first case, a prerequisite is that the destination address/subnet mask exist exactly in the routing table. (In the second case, since it is being redistributed, you know that it is already in the routing table).
BGP requires that any local configurations used to allow a router to learn of networks must have, as a prerequisite, a route to that network in the routing table. This ensures that any network that is advertised using a specific local configuration (network/redistribution) can indeed be reached from that router.
Now notice I’ve stressed “local configuration” in my statements above, refering to the network and redistribution features of BGP. The reason I have done this is because a router can learn about BGP routes from one additional source: neighboring BGP routers. Any routes that are advertised from neighbors and reach a router are automatically put in the BGP table without the prerequisite of requiring an exact mach in the local routing table. From there, the best match is installed in the routing table.
The result is that any routes in the BGP table that are in there because of the network command or redistribution, never enter the routing table as BGP routes, but either as static routes or routes learned by an IGP. Only BGP routes learned from neighbors actually find themselves in the routing table as BGP learned routes.
I hope this has been helpful!
Laz
HI,
Why ibgp requires an IGP routing protocol and BGP does not require igp
Thanks
Hi Sims
Thanks for mentioning this. All of the information stated in the previous post has to do with iBGP, that is, BGP routes that are shared between BGP routers in the same AS.
When configured correctly, an IGP will only function within the boundaries of the BGP AS. No routes should be learned between different BGP AS’es via IGPs such as OSPF or EIGRP. Only BGP should be used to learn routes between BGP AS’es.
It is this very structure of BGP that makes eBGP not require the use of an IGP. The destination that exists outside of the local AS should not be known by any IGP internal to the AS. This is why eBGP does not require the use of an IGP.
I hope this has been helpful!
Laz
You mean iBGP or BGp
What you mean by BGP routes are shared…
Thanks
Can you just simplify this