What is the difference between the network command for IGP and BGP?

dppagc

I understand that for IGP that the network command determines which interface the routing protocol is advertised.
How is this different in bgp?

int lo1
1.1.1.1 255.255.255.0

router bgp 1
network 1.1.1.1 mask 255.255.255.0
! not allowed

only network 2.2.2.2 mask 255.255.255.255 is allowed. Why?

Dieg0M

In BGP, the network will be advertised as long as it is in the RIB and the exact prefix is matched. In your case, 1.1.1.0 255.255.255.0 would be the prefix.

_Gonzalo_

Your issue is simpler, and not limited to BGP: IP and mask do not match. For that mask, you need to use the network address, not the interface´s IP.

1.1.1.0 255.255.255.0

@Diego

I am not sure about what you said... Do you mean that just advertising the ip (network 1.1.1.1 255.255.255.255) it would not advertise the entire network?

Dieg0M

Gonzalo, using network 1.1.1.1 255.255.255.255 would not advertise anything, the prefix to match is 1.1.1.0/24.

dppagc

That is where I am confused with OSPF and BGP.

For ospf I can put

router ospf 1
network X.X.X.X 0.0.0.0 area 0

The wildcard mask (for OSPF) is 0.0.0.0 BUT the ip address mask is not 255.255.255.255.
But the routes still get advertise.

However, for BGP the mask for the ip address and the router bgp must match. Am I right to say that?

Can anyone clarify why bgp and ospf behave differently?

late_collision

The network statements between OSPF and BGP are fundamentally different.

- The network statement in OSPF enables OSPF on an interface, if that interface is assigned an IP address within the range of a network statement.

- The network statement in BGP is used to tell BGP to advertise a prefix (network, subnet, whatever you want to call it). In doing this, the network statement requires a network address.

dppagc wrote: »

That is where I am confused with OSPF and BGP.

For ospf I can put

router ospf 1
network X.X.X.X 0.0.0.0 area 0

The wildcard mask (for OSPF) is 0.0.0.0 BUT the ip address mask is not 255.255.255.255.
But the routes still get advertise.

The routes may get advertised, but is OSPF enabled on that interface? You can check your work with #show ip ospf interface

dppagc wrote: »

However, for BGP the mask for the ip address and the router bgp must match. Am I right to say that?

No, it's not an IP address, it's a network address. 1.1.1.1 255.255.255.0 is not a network address, it's a host address. 1.1.1.0 is the network address, 1.1.1.1 - 1.1.1.254 are host addresses, and 1.1.1.255 is the broadcast.

BGP is very particular about this.

_Gonzalo_

Dieg0M wrote: »

Gonzalo, using network 1.1.1.1 255.255.255.255 would not advertise anything, the prefix to match is 1.1.1.0/24.

I did not know that...

dppagc

Ok I get it. Thanks.

However, for bgp, I can assume that any interfaces assigned an ip address within the range of the network address will have bgp advertised?

late_collision

dppagc wrote: »

However, for bgp, I can assume that any interfaces assigned an ip address within the range of the network address will have bgp advertised?

No, and this is why its difficult to understand the difference of the network statement.

For OSPF, when an interface is enabled via the network statement, that interface then participates in sending/receiving hello's, discovers all neighbors on the link, and forms adjacencies. These adjacencies are "link local" in the fact that they are all directly connected (1 hop away). You cannot form an adjacency with another router that is not directly connected (physically, or virtually (like with a tunnel)).

BGP does not discover neighbors. You must define neighbors using the neighbor statement. BGP neighbors do not have to be "link local", they just have to be reachable at the network layer. That means, you can form a BGP neighborship out any of the interfaces on your local router, so long as they can reach the BGP neighbor (i.e. have a route to it).


(I am running a little late for work, so this post is rushed. Someone may be able to clean up this post if it's confusing.)

dppagc

late_collision wrote: »

No, and this is why its difficult to understand the difference of the network statement.

For OSPF, when an interface is enabled via the network statement, that interface then participates in sending/receiving hello's, discovers all neighbors on the link, and forms adjacencies. These adjacencies are "link local" in the fact that they are all directly connected (1 hop away). You cannot form an adjacency with another router that is not directly connected (physically, or virtually (like with a tunnel)).

BGP does not discover neighbors. You must define neighbors using the neighbor statement. BGP neighbors do not have to be "link local", they just have to be reachable at the network layer. That means, you can form a BGP neighborship out any of the interfaces on your local router, so long as they can reach the BGP neighbor (i.e. have a route to it).


(I am running a little late for work, so this post is rushed. Someone may be able to clean up this post if it's confusing.)

I think I get it. The bgp neighbor is not the "neighbor" or next hop so to speak. It can be far far away.

But so far the labs that I have done involve next hop routers.

Next question.

Can I use the neighbor X.X.X.X Y.Y.Y.Y command if the neighbor is in a different subnet since it is far far away from the originating router?

joetest

dppagc wrote: »

I think I get it. The bgp neighbor is not the "neighbor" or next hop so to speak. It can be far far away. But so far the labs that I have done involve next hop routers. Next question. Can I use the neighbor X.X.X.X Y.Y.Y.Y command if the neighbor is in a different subnet since it is far far away from the originating router?

Think about it - can 2 routers be in the same subnet if they're separated by other routers? And you already know you can make manual BGP neighbors across several hops. (Though there's a reason why eBGP has TTL of 1 meaning you can only talk BGP with the next-hop router in a different AS number(eBGP)) Makes sense?

rjon17469

joetest wrote: »

Though there's a reason why eBGP has TTL of 1 meaning you can only talk BGP with the next-hop router in a different AS number(eBGP)

Default TTL of 1 for eBGP, but configurable.

dppagc

rjon17469 wrote: »

Default TTL of 1 for eBGP, but configurable.

Ok. I got 2 other questions.

1) What is the default ttl for ibgp?

2) For MPLS, why is there an ibgp route from the PE to PE when there is an IGP running between them?

Fitzi

Generally for MPLS and iBGP you would use an IGP only for loopback reach ability as you would have multiple paths between all your routers. The loopback addresses are then used for iBGP peering because they are reachable over all redundant paths. So if you had one particular link fail iBGP stays up because it can still reach its peer via another path to the neighbour iBGP router.

Dieg0M

dppagc wrote: »

Ok. I got 2 other questions.

1) What is the default ttl for ibgp?

2) For MPLS, why is there an ibgp route from the PE to PE when there is an IGP running between them?

1) 255
2) You cannot run only iBGP or IGP, you need both. Without iBGP, you would not be able to carry the VPNv4 routes in an MPLS backbone and that is needed for L3 VPN's. Also, even if it would be possible to carry the VPNv4 routes in an IGP, it would not scale as an IGP can only carry a limited amount of routes compared to BGP. You could not run iBGP without an IGP either. An IGP is needed for the underlying protocol establishment because there are some very notable key differences between an IGP and iBGP. For example, iBGP does not change a prefix next hop attribute and does not provide by default a meaningful metric for path calculation.

Hope this helped.