Route feedback

Yes, I know that this drawing is ugly. Sorry, I'm not a good artist :) Unfortunately...

Entry data:
1. Routing protocol - RIPv2
2. R1 advertises summary route on both it's links
3. S1 is a multipoint interface. R1, R2 and R3 are in the same subnet
4. Split horizon is disabled on S1

Normal network condition: R2 receives update on both links and advertises it through S1 interface back to R1 and to R3 (Split horizon is off). Next-Hop address in the update is R1's serial interface. R1 receives it's own update, check that Next Hop IP in update it's on IP address and discards it. R3 installs the summary into it's routing table with two GW as an NH - R1 and R2. Remember, that R2 advertises both routes to the summary subnet - one through itself and the other one through R1 directly.


Now, suppose, on R2's S1 interface we filter this summary inbound. Now we advertise the summary route that we received on a point to point link (S0 int) back to R1 through the S1. R1 receives it and installs it as a valid route. After several seconds it realizes that it's own route and poisons it (sends this summary to frame-relay link with metric of 16 hops). R2 receives poisoned route, then poisons it back to R1. After some time the process repeats. If we are pinging this summary from R3 sometimes we will receive replies and sometimes we will receive Unreachables (the moment the route is poisoned).

Solution - it wouldn't be a problem at all if R1 installed  a summary to Null0 to it's routing table when it advertised this summary to its neighbors.


I would like to thank INE workbooks for this interesting scenarios. I duplicate it here for future reference and memorizing the concept.

Route filtering

1. Distribution lists

Gateway keyword can be used only with prefix-lists

a. Distribution lists using access-lists.

Common thing among all of the ACL's - it's possible to filter only prefix, but not the prefix-length.

Two types of ACL's can be used:

Standard access-lists can specify the route, but not the origin of the route (i.e. advertising router). Route specified as a host address (0.0.0.0 wildcard bits).

Extended access-lists 

Origin is specified in a source portion of an ACL (host address) and the route being filtered is specified in a destination field.

By origin, I mean NH.

b. Prefix-lists.

My previous post

Logic is following:

distribute-list prefix-list SUBNETS gateway PREFIX_LIST_WITH_NH_IP in

Prefix list PREFIX_LIST_WITH_NH_IP will block everything from the specified NH routers (to deny, use deny keyword) and prefix-list SUBNETS can block any route from the rest of the routes in router database.

Once again. The routes from route sources that are permitted by gateway keyword (with permit statement in prefix-list) can be further filtered with a SUBNETS prefix-list.

The following paragraph applies to both filtering with extended access-lists and filtering with prefix-lists with gateway keyword.

If "gateway" keyword in prefix-list filtering or source IP in extended list filtering is defined under distribution-list command then IP has to be one of a next-hop router, not sending router!!! It's particularity interesting in scenarios with hub-and-spoke topologies where all spokes and hub share the common subnet. When hub sends a route to spoke 1 and the next-hop of a route is spoke 2 (which announced the network to a hub) and you are filtering inbound on spoke 1 and define "gateway" as IP of a hub (next-hop address of a route) - it won't work. You have to specify IP of a next hop!

R3#show ip route 10.200.0.1
Routing entry for 10.200.0.1/32
  Known via "rip", distance 120, metric 2
  Redistributing via rip
  Last update from 10.50.0.2 on Serial0/0.3, 00:00:01 ago
  Routing Descriptor Blocks:
  * 10.50.0.2, from 10.50.0.5, 00:00:01 ago, via Serial0/0.3
      Route metric is 2, traffic share count is 1

In other words, as we see from the output above, we need to filter address 10.50.0.2, and not 10.50.0.5.

2. Distance

What is particularly different in distance VALUE route_source mask ROUTE_ACL is that here we have to specify advertising router's address as a route source, not the NH address as we have seen in previous examples of distribute-list.

  3. Offset lists

With offset lists the ACL that we specify in the command should PERMIT the networks which we want the offset to be applied to (essentially, we select the networks with PERMIT statement and all the networks that are denied with this ACL are ignored by the offset list command).

Understanding Prefix-lists

If only prefix is specified in a permit or deny statement without mentioning le or ge keywords, then the actual route (including prefix length) is matched.
If  le or ge keywords are used, then in a prefix/prefix length we specify how many bits to check for exact match in a route and the actual prefix length of the route is matched by the le or ge keyword.


What was tricky to realize is the difference between the following two commands:


prefix-list DEFAULT permit 0.0.0.0/0 le 32

matches every possible route. Essentially this statement says: check 0 bits of the prefix for exact match and make sure that prefix length is less than 32 bits.

However let's check the next statement:

prefix-list DEFAULT permit 0.0.0.0/0

It was tricky to understand that this prefix-list would match only DEFAULT route.  Everything else is denied!

RIP default route advertisement

To advertise default I did:

int s0/0
ip summary-address rip 0.0.0.0 0.0.0.0

Result: all routes were suppressed from advertisement. Router just stopped sending updates to the neighbors.

Tricks of the "distribute-list" OSPF subcommand

The citation is from the Cisco Press ROUTE Official Cert Guide.

The mechanics of the distribute-list router subcommand has a few surprises, which are
summarized in this list:

• The command requires either an in or out direction. Only the in direction works for filtering routes as described in this section.

• The command must refer to either a numbered ACL, named ACL, prefix list, or route map. Regardless, routes matched with a permit action are allowed into the routing table, and routes matched with a deny action are filtered.

• Optionally, the command can include the interface interface-name-and-number parameters. The router compares these parameters to the route’s outgoing interface.

Choice of the best route from the ABR perspective

When choosing the best route to reach any given subnet, ABRs follow the next two rules:

1. Intra-area route is always better, than a competing inter-area route, regardless of metric;
2. Ignore Type 3 LSA learnt in non-backbone area.

Meaning of LSID for different OSPF LSA types

Type 1 LSA's list RID as a LSID
Type 2 LSA's list DR's interface IP address for the subnet as a LSID
Type 3 LSA's list subnet number being advertised as a LSID

Propagation of default route into EIGRP domain

Two main options exist:
1. Configure static default route and then redistribute it into EIGRP;
2. Configure default-network command that should point toward the network connected to gateway router (for example, it could be it's WAN subnet or just loopback host route). This command could be configured at the Enterprise edge router that have default route or full routing table. All routers in EIGRP domain will mark this newly learnt network as "candidate default". The most easily understandable explanation for me is that we should mark network as default if we know that when packet from anywhere of the inside network reach the router connected to this network it will know how to further forward this packet.

EIGRP Citation

About routers going Active and querying their neighbors.

From the CCNP ROUTE Cert Guide:

If a router receives an EIGRP Query for a prefix/prefix length, does not have an exactly matching (both prefix and prefix length) route, but does have a summary route that includes the prefix/prefix length, that router immediately sends an EIGRP Reply and does not flood the Query to its own neighbors.

Route filtering by means of distribution lists with ACLs, IP Prefix Lists and Route Maps

When using ACLs with Distribution lists, the most confusing thing for me is that:

1. Deny statement in ACL is used to deny the route from being accepted or sent;
2. If there is no "Permit Any" in the end of ACL then it will "pass" only routes explicitly mentioned with "Permit" statement.

I'm used to know, that to "catch" something, ACL's should do it with "Permit" statement (for example, this is the case when using distribution lists with route maps).

IP Prefix Lists use the same logic:

"Each command has a permit or deny action, but because it is used only for matching routes, and not for packet filtering, the permit or deny keyword just implies whether a route is matched (permit) or not (deny)." - CCNP ROUTE Off Cert Guide.

So, to permit the route in distribution list, "Permit" statement must be used in IP Prefix List and to deny the route "Deny" statement is used. As always, at the end of list is implicit "Deny All" statement.

Making a router with NAT from Windows XP without enabling ICS

I've always wanted to know how to enable routing and NAT on XP box without enabling ICS (Internet Connection Sharing). Today it's time to write some lines about it. Let's begin.
1. We should enable service "Routing and Remote Access"
2. Open registry editor and navigate to "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters" and set IPEnableRouter to "1"

Then, open a command prompt and type the following commands:
3. netsh routing ip nat install
4. netsh routing ip nat add interface "WAN Interface Name" full
5. netsh routing ip nat add interface "LAN Interface Name" private

I'm not sure whether computer has to be restarted after this setup, but the answer is probably "yes".
Anyway, if something doesn't agree to work - just restart the computer before panic :D

P.S. One more thing to add:  
To check configured interfaces type netsh routing ip nat show interface

BGP synchronization

BGP Synchronization Rule
The BGP synchronization rule states that a BGP router should not use, or advertise to an external neighbor, a route learned by IBGP, unless that route is local or is learned from the IGP.

If synchronization is enabled and your autonomous system is passing traffic from one autonomous system to another, BGP should not advertise a route before all routers in your autonomous system have learned about the route via IGP. In other words, BGP and the IGP must be synchronized before networks learned from an IBGP neighbor can be used.

Routes redistribution and Administrative distance manipulation

I've seen the great example of problems with 2-way redistribution of routes between OSPF and RIP.

When we redistributing routes from RIP domain to OSPF on both P3R1 and P3R2, the curious thing happens. Let's say redistribution is configured on P3R1, then P3R2 will have only OSPF routes in it's routing table. The routes from RIP domain will have next-hop IP address on s0/0/0 interface of P3R1! Even loopback address on directly connected P3R4! This situation, of course, leads to suboptimal routing decisions.
One of the ways to fix the problem is to change administrative distance of OSPF routes learned via redistribution. We can rise the AD of these routes to make them appear less attractive then native RIP routes. In this way, native RIP routes will appear in the routing table instead of redistributed into OSPF routes.

hostname P3R2
!
router ospf 1
redistribute rip metric 10000 metric-type 1 subnets
network 172.31.0.0 0.0.255.255 area 0
distance 125 0.0.0.0 255.255.255.255 64
!
router rip
version 2
redistribute ospf 1 metric 5
network 10.0.0.0
no auto-summary
!
access-list 64 permit 10.3.1.0
access-list 64 permit 10.3.3.0
access-list 64 permit 10.3.2.0
access-list 64 permit 10.200.200.31
access-list 64 permit 10.200.200.32
access-list 64 permit 10.200.200.33
access-list 64 permit 10.200.200.34

Now the router will keep original AD of all native OSPF routes, except routes redistributed from OSPF(these routes will have AD of 125 > than native RIP routes).

The most important feature of using administrative distance to control route preference is that no path information is lost; in this example, the OSPF information is still in the OSPF database. If the primary path (via the RIP routes) is lost, the OSPF path reasserts itself, and the router maintains connectivity with those networks.

P.S. Routes must be in the routing table for them to be redistributed.

Understanding and Configuring VLAN Routing and Bridging on a Router Using the IRB Feature

In order for a VLAN to span a router, the router must be capable of forwarding frames from one interface to another, while maintaining the VLAN header. If the router is configured for routing a Layer 3 (network layer) protocol, it will terminate the VLAN and MAC layers at the interface a frame arrives on. The MAC layer header can be maintained if the router is bridging the network layer protocol. However, regular bridging still terminates the VLAN header. Using the IRB feature in Cisco IOS^® Release 11.2 or greater, a router can be configured for routing and bridging the same network layer protocol on the same interface. This allows the VLAN header to be maintained on a frame while it transits a router from one interface to another. IRB provides the ability to route between a bridged domain and a routed domain with Bridge Group Virtual Interface (BVI). The BVI is a virtual interface within the router that acts like a normal routed interface that does not support bridging, but represents the comparable bridge group to routed interfaces within the router. The interface number of the BVI is the number of the bridge group that the virtual interface represents. The number is the link between the BVI and the bridge group.
When you configure and enable routing on the BVI, packets that come in on a routed interface, which are destined for a host on a segment in a bridge group, are routed to the BVI. From the BVI, the packet is forwarded to the bridging engine, which forwards it through a bridged interface. This is forwarded based on the destination MAC address. Similarly, packets that come in on a bridged interface, but are destined for a host on a routed network, first go to the BVI. Next, the BVI forwards the packets to the routing engine before it sends them out of the routed interface. On a single physical interface, the IRB can be created with two VLAN sub-interfaces (802.1Q tagging); one VLAN sub-interface has an IP address that is used for routing, and the other VLAN sub-interface bridges between the sub-interface used for routing and the other physical interface on the router.
Since the BVI represents a bridge group as a routed interface, it must be configured only with Layer 3 (L3) characteristics, such as network layer addresses. Similarly, the interfaces configured for bridging a protocol must not be configured with any L3 characteristics.
Standard design:

As the frame flows through the switch, the VLAN header is applied because the connection is a trunk link. There may be several VLANs communicating across the trunk.
The router terminates the VLAN layer and the MAC layer. It examines the destination IP address and forwards the frame appropriately. In this case, the IP frame is to be forwarded out of the port toward PC B. This is also a VLAN trunk and so a VLAN header is applied.
Although the VLAN connecting Switch 2 to the router can be called the same number as the VLAN connecting Switch 1 to the router, it is actually not the same VLAN. The original VLAN header is removed when the frame arrives at the router. A new header may be applied as the frame exits the router. This new header may include the same VLAN number that was used in the VLAN header that was stripped when the frame arrived. This is demonstrated by the fact that the IP frame moved through the router without a VLAN header attached, and was forwarded based on the contents of the IP destination address field, and not on a VLAN ID field.
Because the two VLAN trunks sit on opposite sides of the router, they must be different IP subnets.
In order for the two PCs to have the same subnet address, the router would have to be bridging IP on its interfaces. However, having the devices on VLANs share a common subnet does not mean that they are on the same VLAN.
IRB:

 Sample config:

Current configuration:
!
version 12.0
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname R1
!
!
ip subnet-zero
no ip domain-lookup
bridge irb
!-- This command enables the IRB feature on this router.!
interface Ethernet0
no ip address
no ip directed-broadcast
bridge-group 1
!-- The interface E0 is in bridge-group 1.!
Interface Ethernet1
no ip address
no ip directed-broadcast
bridge-group 1
!-- The interface E1 is in bridge-group 1.!
Interface Serial0
ip address 10.10.20.1 255.255.255.0
no ip directed-broadcast
no ip mroute-cache
no fair-queue
!
interface Serial1
no ip address
no ip directed-broadcast
shutdown
!
interface BVI1
ip address 10.10.10.1 255.255.255.0
!-- An ip address is assigned to the logical BVI for routing!-- IP between bridged interfaces and routed interfaces.no ip directed-broadcast
!
ip classless
ip route 10.10.30.0 255.255.255.0 10.10.20.2
!
bridge 1 protocol ieee
!-- This command enables the bridging on this router.bridge 1 route ip
!-- This command enable bridging as well routing for IP protocol.!
line con 0
transport input none
line aux 0
line vty 0 4
!
end