How a router knows which interface to advertise routing protocol messages?

johnifanx98

I understood usually routers are interconnected on serial interfaces. Does it mean a router will by default advertise its protocol messages to all its serial interfaces?

Any possibility it will send advertisement to its ethernet port?

sratakhin

A router will not advertise anything by default. Only the directly connected will be shown in the routing table, until you add static routes or turn on any of the routing protocols on at least two routers. After you do it, you can choose which networks to advertise.

synseq

This is done through route summarization. If you are interested I can give you a web link that explains route summarization it even has diagrams to go with the process of setting up and explaining route summarization. You want to use route summarization to advertise multiple routes with only one line in an update packet thereby reducing the size of the update and allowing more bandwidth for data transfer. At the same time when the router does a lookup in its routing table to determine which interface the traffic must be sent out on the larger the routing tables the longer this process takes leading to increased router CPU cycles to perform the lookup. So route summarization saves bandwidth and minimizes the amount of time and router CPU cycles that are used.


Edit: sorry I misread your post but I will leave the information because when you start to set that up it might come in handy.

NetworkVeteran

johnifanx98 wrote: »

I understood usually routers are interconnected on serial interfaces. Does it mean a router will by default advertise its protocol messages to all its serial interfaces?

Routers can be interconnected many ways, including Ethernet interfaces. Routers, by default, do not send routing updates out any interfaces. They only send routing updates out only those interfaces you've configured them to send routing updates on.

Router# conf t
Router(config)# int fa0/0
Router(config-if)# ip ospf 1 area 0

MrBrian

You tell the router on which interfaces to activate the routing protocol.. you do this by using the network statement under the routing instance.. or, like the previous example showed, you can activate the protocol on an interface from interface level configuration (I think that's only for ospf though).

It's easy to just use a network statement and wildcard to encompass all the interfaces you need. Then those interfaces will send out hello's if it's eigrp or ospf, or just updates for rip.

NetworkVeteran

MrBrian wrote: »

you can activate the protocol on an interface from interface level configuration (I think that's only for ospf though).

You can configure most interior routing protocols that way. It's the direction Cisco seems to be moving towards with respect to routing protocol configuration.

Router# conf t
Router(config)# int fa0/0
Router(config-if)# ip router isis
Router(config-if)# ipv6 router isis
Router(config-if)# ip ospf 1 area 0
Router(config-if)# ipv6 ospf 1 area 0
Router(config-if)# ipv6 eigrp 65001
Router(config-if)# ipv6 rip NetworkVeteran enable

Compare the examples below, which all do the same thing. I would argue that the first is the most straight-forward, the second requires some calculation, and the third is likely to confuse folks who don't fully grasp the specifics of the network command.

Example #1
Router# conf t
Router(config)# int fa0/0
Router(config-if)# ip address 192.168.1.9 255.255.255.248
Router(config-if)# no shutdown
Router(config-if)# ip ospf 1 area 0

Example #2
Router# conf t
Router(config)# int fa0/0
Router(config-if)# ip address 192.168.1.9 255.255.255.248
Router(config-if)# no shutdown
Router(config-if)# exit
Router(config)# router ospf 1
Router(config)# network 192.168.1.8 0.0.0.7 area 0

Example #3
Router# conf t
Router(config)# int fa0/0
Router(config-if)# ip address 192.168.1.9 255.255.255.248
Router(config-if)# no shutdown
Router(config-if)# exit
Router(config)# router ospf 1
Router(config)# network 192.168.1.9 0.0.0.0 area 0

I will admit to making liberal use of "network 0.0.0.0 255.255.255.255 area 0" in labs.

In real networks I tend to be more precise in my configurations.

johnifanx98

MrBrian wrote: »

You tell the router on which interfaces to activate the routing protocol.. you do this by using the network statement under the routing instance.. or, like the previous example showed, you can activate the protocol on an interface from interface level configuration (I think that's only for ospf though).

It's easy to just use a network statement and wildcard to encompass all the interfaces you need. Then those interfaces will send out hello's if it's eigrp or ospf, or just updates for rip.

I found passive-interface which is to disable updates on certain interfaces. So, I guess for RIP by default, it's sending updates to all involved interfaces...

sratakhin

NetworkVeteran wrote: »

I will admit to making liberal use of "network 0.0.0.0 255.255.255.255 area 0" in labs.
In real networks I tend to be more precise in my configurations.

Yeah, why waste precious time?

NetworkVeteran

johnifanx98 wrote: »

So, I guess for RIP by default, it's sending updates to all involved interfaces...

RIP only sends updates out the interfaces you enable it on, just like other routing protocols.

NetworkVeteran

johnifanx98 wrote: »

I found passive-interface which is to disable updates on certain interfaces.

Suppose you have a device configured as follows--

fa0/0 - 10.3.1.1/24
fa0/1 - 10.3.2.1/24
fa0/2 - 10.3.3.1/24
fa0/3 - 10.6.1.1/24
fa0/4 - 10.6.2.1/24

You want RIP to run only on 10.3.x.x. This is how you would accomplish that--

router rip
passive-interface fa0/3
passive-interface fa0/4
network 10.0.0.0

Before the network 10.0.0.0 command, RIP is enabled nowhere. After that command, RIP is enabled on interfaces fa0/0, fa0/1, and fa0/2. Hope this helps.

Forsaken_GA

johnifanx98 wrote: »

I found passive-interface which is to disable updates on certain interfaces. So, I guess for RIP by default, it's sending updates to all involved interfaces...

The reason for passive interface is because sometimes you want to advertise that interface and it's subnet into OSPF/EIGRP/RIP, but you do not want to form any adjacencies over it (in the case of EIGRP/OSPF) or you don't want to actually send any advertisements out the interface (in the case of RIP).

Think of the case where you have a router port facing an access network where only users will reside. Those users need to communicate, so the prefix needs to be in the routing table. However, it'd be a really bad idea to let users form router adjacencies. There are a few ways to get the prefix into the routing table, but the easiest way (and the way less likely to actually effect anything else) is to activate the interface in the routing protocol and then set it passive.

Personally, my standard method of configuration is to set passive-interface default on whatever routing protocol I'm configuring, and then issue no passive-interface <int name> on the links where I want routing information exchanged. I find this tends to limit route injection screwups nicelyl

Forsaken_GA

NetworkVeteran wrote: »

I will admit to making liberal use of "network 0.0.0.0 255.255.255.255 area 0" in labs.

Yeah, I used to, until I started studying ipv6. Since it requires you to activate at the interface level, I've gotten into the habit of doing that with ospf. Annoys me every time I have to configure EIGRP or RIP and can't do the same.

Forsaken_GA

NetworkVeteran wrote: »

Suppose you have a device configured as follows--

fa0/0 - 10.3.1.1/24
fa0/1 - 10.3.2.1/24
fa0/2 - 10.3.3.1/24
fa0/3 - 10.6.1.1/24
fa0/4 - 10.6.2.1/24

You want RIP to run only on 10.3.x.x. This is how you would accomplish that--

router rip
passive-interface fa0/3
passive-interface fa0/4
network 10.0.0.0

Before the network 10.0.0.0 command, RIP is enabled nowhere. After that command, RIP is enabled on interfaces fa0/0, fa0/1, and fa0/2. Hope this helps.

That's not entirely true. Under that configuration, RIP would be running on all the interfaces, but not sending routes on the passively defined ones. It would still be accepting routes on the passive interfaces, which may not be the desired effect.

The only reason passive-interface effectively disables OSPF and EIGRP is because it suppresses the outgoing hello messages as well, and those two protocols require establishment of 2 way communications prior to route exchange. RIP has no such requirement.

NetworkVeteran

Forsaken_GA wrote: »

That's not entirely true. Under that configuration, RIP would be running on all the interfaces, but not sending routes on the passively defined ones.

True enough. In the above configuration, I did trigger RIP to run on those interfaces, I simply stopped it from sending updates out of them. There is no way afaik to trigger RIP to run on 10.3.x.x but not run on 10.6.x.x. You can come very, very close--

access-list 10 deny any
access-list 20 permit 10.3.0.0 0.0.255.255
router rip
_passive-interface fa0/3
_passive-interface fa0/4
_distribute-list 10 in fa0/3
_distribute-list 10 in fa0/4
_network 10.0.0.0
_distribute-list 20 out

In this case, for fa0/3 and fa0/4 RIP will not send updates, not receive updates, nor make any other device aware of the presence of their subnets.

Forsaken_GA

NetworkVeteran wrote: »

True enough. In the above configuration, I did trigger RIP to run on those interfaces, I simply stopped it from sending updates out of them. There is no way afaik to trigger RIP to run on 10.3.x.x but not run on 10.6.x.x. You can come very, very close--

Right, it's one of the pain in the asses of RIP that it's network command matches classfully even when running version 2 with no auto-summary. If you control both sides of the link and can passive both sides out, no big deal. But going back to my use case of a user facing router port, I'd never want to run RIP there, not when any idjut with a linksys router can flip RIP on and effect my routing table.

The distribute list works. My preferred solution would be to apply an inward facing extended ACL that matched and denied RIP traffic. Either way works, the important thing is being aware of the details of how the protocols work and how you can mitigate their occasional shortcomings