Fundamentals Of Route Redistribution

Golden Rules about Route Redistribution:-
1. Routes can be redistributed from one routing protocol to another. This is the assumption which we are working. But this is not true, routes are not redistributed from one protocol to another. Routes are always taken from RIB not from a routing protocol.

2. The redistributing protocol knows which routes to take from the RIB based on the “known via” information present in "show ip route" details.

3. A route must be installed in the RIB for it to be redistributed in another protocol.

4. Routes redistributed from the routing table are not re-installed again into the RIB.

5. Only the attributes of a route present in the RIB can be used for filtering.

Redistribution Filters:-
1. Redistribution filters can control what information is injected into a routing protocol through redistribution.

2. Filters can also be used to stop routing loops(Read more about layer 3 routing loops) when mutual redistribution between two routing protocols is configured.

Redistribution Filter Tools:-
1. Match metric:- Filtering is possible between all protocols based on metric used.

2. Match Tag:- While mutual redistribution, TAGs can be assigned to routes to stop the routing loop too.

3. Match IP Address:- Matches the prefix, possibly the network mask, depending on the access list type used.

4. Match IP Next Hop Address:- Matches on the next hop listed in the routing table.

5. Match route-type

6. Match Interface


Click Here To Read Rest Of The Post...

Facts About Static Routing

Static routing is one of the easiest way to define reachability among the different networks but is only helpful if you are in stub network (A network which is having a single exit point) or is usefully for small networks. Static routing can be defined with different types of exit interface. Below is the various types of defining static routing.

1.Static routes can have next hop address of an IP Address:-
ip route 10.2.2.0 255.255.255.0 10.1.2.1. Defining this type of route causes the RIB and CEF to recursively lookup the correct layer 2 header to rewrite onto the packet. As long as the next hop is reachable, the router assumes the destination through that next hop is reachable.

2.Static routes can have next hop address as point to point interface address:- ip route 10.2.2.0 255.255.255.0 serial0. The RIB and CEF point the route directly at the point-to-point interface. For each packet destined to 10.2.2.0/24, the layer 2 rewrite header is set up to reach the other end of the point-to-point link. As long as the interface is up, the router assumes the destination is reachable through that interface.

3.Static routes can have next hop address as broadcast interface:- ip route 10.2.2.0 255.255.255.0 fa0/0. If you point a static route to a broadcast interface, the route is inserted into the routing table only when the broadcast interface is up. This configuration is not recommended because when the next hop of a static route points to an interface, the router considers each of the hosts within the range of the route to be directly connected through that interface. With this configuration, router assumes all the interfaces are directly connected and performs the ARP request for every destination. This configuration increases the IP Input and consumes lot of memory to store the arp entries. This configuration requires enabling proxy ARP on routers, if it is not enabled will lead to drop the packets.

For default routes with outgoing interface as broadcast interface could lead to 2 raise to power 32 entries in the ARP table.


Click Here To Read Rest Of The Post...

RFC 1998 Defining BGP Communitites

The BGP community attribute is a very powerful tool for assisting and scaling BGP at any level.

Most of the ISPs make extensive use of BGP communities while defining internal policies, Inter-provider relationships and Customer traffic engineering. There is no such standard defined for these communities but still RFC 1998 has community values which defined to have particular meaning:-

• ASx:100 :- This community says set local preference to 100 and make this path as preferred path.
• ASx:90:- This community says set local preference to 90 and make this path as backup if dual homed to ASx.
• ASx:80:- This community says set local preference to 80. This link is to another ISP with same AS path length.
• ASx:70:- This community says set local preference to 70. This link is to another ISP.
These communities are defined by the upstream ISP. All the customers which are homing to ISP, they can attach these communities while advertising the routes.

For Example:-
If upstream ISP is AS 200; To declare a particular path as a backup path, their customer would announce the prefix with community 100:70 to AS200. ISP with AS200 would receive the prefix with the community 100:70 tag, and then set local preference to 70.

Customer Configuration Template
router bgp 65000
neighbor x.x.x.x remote-as 200
neighbor x.x.x.x description Backup ISP
neighbor x.x.x.x route-map as200-out out
neighbor x.x.x.x send-community
!
ip as-path access-list 20 permit ^$
!
route-map as100-out permit 10
match as-path 20
set community 100:70
!
Sample ISP Router Configuration

router bgp 200
neighbor y.y.y.y remote-as 65000
neighbor y.y.y.y route-map customer-policy-in in
!
! Homed to another ISP
ip community-list 7 permit 200:70
! Homed to another ISP with equal ASPATH length
ip community-list 8 permit 200:80
! Customer backup routes
ip community-list 9 permit 200:90
!
route-map customer-policy-in permit 10
match community 7
set local-preference 70
!
route-map customer-policy-in permit 20
match community 8
set local-preference 80
!
route-map customer-policy-in permit 30
match community 9
set local-preference 90
!
route-map customer-policy-in permit 40
set local-preference 100

Click Here To Read Rest Of The Post...

BGP Redistribution Vs MPLS

If someone asks you to select between BGP Redistribution in IGP Vs MPLS, which one you would like to opt. In layman's terms both are different and has nothing to do with each other. But as per MPLS Advantages, MPLS is used to reduce the number of routes from the core. But those routes are VPNv4 routes(MP-IBGP) not the iBGP redistributed routes.

It is not mandatory that MPLS is only required for VPNs. MPLS can be used for normal routing also where a enterprise customer is having some external routes and not willing to propagate those routes in the core of network.

Below is the topology used for simulation:-

The above topology is used in BGP Synchronization Rule post and end to end IP Prefixes are reachable via redistribution. But the same can be achieved by using MPLS in the network. If MPLS is implemented end to end, there is no requirement of redistribution which saves lot of money of customer.
Click Here To Read Rest Of The Post...

BGP Synchronization Rule

BGP synchronization rule refers to prefix synchronization between BGP and IGP. If it is enabled, BGP speakers will not advertise routes learned from an iBGP peer unless the destination described in the route is also reachable through the local IGP.

Below is the topology used for simulating BGP Synchronization rule by enabling command "SYNCHRONIZATION" under BGP process.

R7-R4-R5 and R6 is running OSPF as routing protocol. R6 and R7 is having iBGP peering with source address loopback 0. Loopback 100 is advertised on routers R6 and R7 and synchronization is enabled under BGP process.

R7 is learning R6 loopback 100 but that prefix is not considered as best prefix because it is not available in the routing table. (Read More About Different Types of BGP Tables)

Now check the output of routing table:-

This means, If a BGP learned prefix is not synchronized, the prefix will not be inserted into the routing table and will not be advertised to external peers. Now we will disable the synchronization rule and checks will routing table now install the iBGP advertised prefix or not. Below is the output of BGP table adter disabling synchronization rule:-

Below is the output of the routing table after disabling synchronization rule:-

We can verify now BGP is installing the prefix 100.100.100.6 as best route in the BGP table and the same prefix is available in routing table too. Now we have the iBGP learned routes in both the routers R6 and R7. Let's initiate the ping from R7 to R6 loopback 100. The ping packets are continuous dropped because R4 and R5 routing table doesn't has the R6 loopback-100 installed in their routing table.

To become the prefix reachable, BGP prefixes must be redistributed into OSPF. Once the redistribution is performed both iBGP prefixes become reachable to each other. This workaround is really painful as all the routes will get flooded into the core routers R4 and R5. Is there any other workaround is available? Wait for the next post to learn the workaround without redistributing the BGP into OSPF.
Click Here To Read Rest Of The Post...

BGP Next-Hop-Self

I have seen lot of guys which say that next-hop-self feature in BGP is used for the E-BGP peering. But with the given case study all of you come to know that It is very practical in I-BGP session in SP domain usually when the customers use static routes.

This case study is divided into two parts:-
a)IP-VPN
b)MPLS-VPN
IP-VPN
In SP cloud, 4*7200 routers are configured as per the diagram. Every router is having IPV4 peering with RR router. OSPF is using for IGP.CE – PE is configured with static routing. All wan links are /30 and loopback addresses are /32.

RR Config is given below:-

I know you will be amazed to see the new config in the BGP. But don’t afraid let’s understand that. The BGP templates introduced in Cisco IOS releases 12.3T, 12.4, 12.2S and 12.2SBC allow you to group session-specific and routing-policy-specific BGP settings into templates with a hierarchical inheritance structure. The peer-session templates define all session-specific parameters (for example, update-source, ebgp-multihop, password, remote-as or local-as), while the peer-policy templates define parameters that influence routing policies, route filters, community propagation and generation of BGP updates The peer-session template is applied to the global neighbor definition. The peer-policy template needs to be applied to a neighbor for each address family in which the neighbor is activated.

Requirement:- CE1 is having one loopback address i.e 10.1.1.1/32 and it is directly attached with the PE1. CE has a default route towards PE1 and CE1 wants that its another location which is CE2 should able to access its loopback. In SP cloud we added a static route of 10.1.1.1/32 towards CE1. But for reachabilty thi default route should be advertised in the SP IGP cloud, but the worse effect of doing this is in the increase of E2 route. So this is not a scalable solution of doing this. Another solution is that this route can be advertised in the BGP and with the help of RR, it will be advertised in the whole cloud. It means no more E2 routes and this solution is scalable one. So we opt the latter solution and advertise the client static route in the BGP.

After this the route should be advertised to RR. You can see with the help of given command.

Now lets come to the RR and check the update.

Hey, Its getting the update of 10.1.1.1/32 as next hop 172.168.2.2. Now the next step is that this route should be advertised to the other client’s also.

In the highlighted line it i showing that the route i not advertised to any peer. Next to this line its is showing that the route i being recived by RR-Client i.e 10.10.10.1 with next hop 172.168.2.2 (inaccessible). What does this inaccessible means, it means the next hop which is 172.168.2.2 is not in the routing table. So from here you got the clue and now check the routing table of RR.

So from the routing table, it is cleared that the next hop is not reachable thats why RR is not advertising this route to its others peer. This problem can be traced on the first level also, see the figure 4 which cleary states that the route in the BGP table is not the best thats why it is not marked with the > sign. So you can check the other peers BGP table also.

Lets analyse the problem carefully. Why the next hop is not present in the routing table. Usually we never advertise the PE-CE links in SP IGP routing table. I know now will be thinking of that why not advertise this PE-CE link in the OSPF or redistributed connected in the OSPF. Yes, you can do this but it will impose another E2 routes and any time when customer link will down your PF will be calculated. Thats why it is not a scalable solution to advertise in the SP IGP. Another question comes in the mind advertise PE-CE directly connected link in the BGP. It really looks sound. Lets try and see the results.

Output of RR after advertising PE-CE wan link in BGP

Output of PE2 after advertising PE-CE wan link in BGP

Output of P after advertising PE-CE wan link in BGP

From the above outputs it is cleared that now the route is in the all SP routers. Lets check from the customer end.
SHIVLU-CE2#ping 10.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 604/708/868 ms
SHIVLU-CE2#
Hurra, Its working fine. Now you are thinking that this is the first-rate solution, But actually the main disadvantage of the soulution is that for every customer we will be getting one extra route i.e wan route which i consuming your router’s memory and ofcourse processes also. From the above outputs we can conclude that the clients route can reachable if I reach to that PE router and from that PE router we are having static route for that client. Lets think is it possible for all clients. It means if my PE will advertise all the static routes of clients with its loopback address then all the clients would be reachable. For this we can use the next-hop-self in the BGP peering with RR.

Now lets analyse the other routers output.
RR Output

PE2 Output

E2 Output
SHIVLU-CE2#ping 10.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:
!!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 560/1018/1292 ms
SHIVLU-CE2#
MPLS-VPN
I am not going to explain the case of MPLS-VPN. The Only difference is that instead of IPV4 peering, will be having VPN-V4 peering and clients will be part of VRF.

Click Here To Read Rest Of The Post...

CEF Adjacency Table Entry

Previous post talks about the CEF FIB Table Entries which resides in the FIB table. As we know CEF is built of two tables one is FIB and another is Adjacency. We will talk more about the different kind of adjacencies available in the CEF table.

• Auto adjacencies actually contain a MAC header rewrite string, and can be used to forward traffic. These are either valid, meaning they are useable, or invalid, meaning the MAC header rewrite string isn’t available.

• Punt adjacencies indicate the packet should be queued to the next slower switching method (generally fast switching) because switching the packet requires a feature that isn’t supported in the CEF switching path. Generally, in newer code, punt adjacencies should be rare.

• The glean adjacency indicates the destination should be directly attached and reachable via a broadcast network, but there is no MAC header rewrite string available to forward traffic.

• Drop adjacencies indicate the packet cannot be CEF switched, but there is no alternate switching path to punt the packet.

• Discard adjacencies indicate the packet should be dropped because it is destined to a loopback address on the router. All the addresses that fall outside the loopback’s actual address (which will have a /32 receive FIB entry) will point to discard adjacencies.

• Any addresses which should be forwarded through a NULL interface on the router (NULL0), will point to the null adjacency.

• The FIB can cache a copy of the MAC header rewrite string directly in the FIB entry itself for faster lookups; load shared destinations cannot have their MAC header rewrite strings cached, so their adjacencies are marked uncached.

(Difference between Optimum, Fast and CEF Switching)

Click Here To Read Rest Of The Post...

CEF FIB Table Entries

Cisco Express Forwarding aka CEF is made of two tables called Forwarding Information Base(FIB) and Adjacency table. Every table has its own data structure and passes some kind of information about the destination network.

CEF FIB table has special type of entries as listed below:-
1. Attached FIB entry:- Attached FIB entries are built for destinations which are actually attached to the router and for destinations which are configured via static routes to appear connected to the router e.g. ip route x.y.z.x via an interface.
2. Connected Entry:- A FIB entry is marked as connected entry if it is actually created because of an ip address command on a router’s interface.
3. Receive FIB Entry:- Receive FIB entries are built when the router should receive (process locally) packets destined to the address.
4. Recursive FIB Entry:- Recursive FIB entries indicate that the destination is reachable through some other route (Normally happens when the interface is not directly connected).

(How to check that the packets are CEF switched or Process Switched)

Click Here To Read Rest Of The Post...

What is Discard Route or NULL0 Route?

What is Discard Routes and how does it help to stop layer 3 routing loops? As we know the fact that loops are not only originates in layer2 network but could also originate in layer 3 networks. We have various mechanisms to prevent layer 3 routing loops with spit horizon and route poisoning.

Would like to understand; IS there any kind of other scenario where in routing loop could exist? See the below infographic

As depicted above, routing loop could occur whenever a summary route is announced towards the peer. This loop could be stopped by creating a manual discard route pointing towards null interface.

IP Route 10.2.0.0 255.255.0.0 null0

OSPF, IS-IS and EIGRP automatically creates discard route whenever summary is performed on the routers.


Below are the configurations for disabling discard routes:-
OSPF
router ospf 1
no discard route

EIGRP
interface serial0 ip summary-address eigrp 1 10.2.0.0 255.255.0.0 255


Click Here To Read Rest Of The Post...

OSPF Fast Convergence Tools - Updating RIB

RIB (Routing Information Base) update is the last post of OSPF fast convergence series whereas earlier posts have already covered OSPF Event Detection, OSPF Event Propagation and OSPF Event Processing.

Whenever there is change of interface state arises, OSPF detect that change and according to that Dijkstra runs the algorithm and update the RIB table according to that. This process is time consuming and requires lot of CPU and memory cycles.

Reducing convergence time depends how fast the OSPF detects the state change and notifies the RIB. In OSPF we normally perform the summarization of the prefixes on ABR and ASBR, this is done only to save the CPU cycles so that every state change information is not flooded across the OSPF routing domain.

Secondly, interface purge command can be used to reduce convergence time. This optimization allows interface link state changes to directly impact RIB rather than waiting for routing protocol updates to RIB to take place.

(Read More About OSPF High Availability)

Click Here To Read Rest Of The Post...

OSPF Fast Convergence Tools - Event Processing

OSPF Event Processing is the third post about OSPF fast convergence tool, earlier posts have already covered OSPF Event Detection and OSPF Event Propagation.

OSPF event processing is all about how to throttle SPF calculations and increase the OSPF convergence time. Event processing is having three different tools as below listed:-
• OSPF SPF Calculations
• OSPF SPF Throttling
• OSPF Incremental SPF

OSPF SPF Calculations:- OSPF full calculations are only triggered by LSA1 and LSA2 where as partial SPF is triggered by LSA 3, LSA 4, LSA 5 and LSA 7.

OSPF SPF Throttling:- OSPF Event propagation deals with the LSA throttling whereas OSPF Event processing deals with SPF throttling. SPF and iSPF(increment SPF) cab be rate limited to delay calculations and save lot of network resources during when the network is not stable. We can throttle only full SPF and iSPF not the partial SPF. Below is the command line to configure SPF throttling:-
router ospf 10
timers throttle spf (start) (hold) (max)

start:[default = 5000 ms] Initial SPF schedule delay in milliseconds.
Recommendation = 10 ms

hold:[default=10000 ms] Minimum hold time between two consecutive SPF calculations. Range is 1 to 600000 milliseconds.
Recommendation = 100 ms

max:[default = 10000 ms] Default ‘timers spf spf-holdtime’ value was 10s. Setting max-interval to 10000 ms provides response equivalent to pre SPF throttle.
Recommendation = 5000 ms


OSPF Incremental SPF:- Before the introduction of iSPF, Dijkstra Algorithm is run by all the routers whenever there is any state change occurs in the OSPF routing area. This requires lot of CPU and memory and wastes lot of resources.

So iSPF helps Dijkstra to run the algorithm only at the change portion of the OSPF tree for LSA 1 and LSA 2 only. This process saves lot of CPU and memory resources consequences reduce OSPF network convergence.

router ospf 10
network 0.0.0.0 255.255.255.255 area 0
ispf

(Read More About OSPF High Availability)

Click Here To Read Rest Of The Post...