palab

Small office requirement

  1. Set up PaloAlto1 and 2 to be active passive HA.
  2. Set up SW5 and SW6 as HSRP routers, vlan 100 towards the external and vlan 10 towards the internal.
  3. HSRP for vlan 10 and vlan 100.
  4. SW4 is a pure layer 2.
  5. PaloAlto HA must have NAT for internet

Configuration will be configured from Win7, R is an out of band switch for managing the devices.

Palo Alto limitation

the VM edition of PA has some limitation as compared to its appliance counterpart.

  1. The VM does not support aggregate ethernet group (lacp).
  2. Does not support multi-vsys.
  3. Only supports active-passive HA.
  4. Only HA1 (control link) and does not have HA2 (data link) as compared to the appliance.

PaloAlto1 and 2 mgmt interface

defaultpa1

both firewall will have the same mgmt ip address as shown above. The first step is to set the mgmt interface and use the web user interface to configure. Palo Alto has a very well design web user interface which makes configuration much easier than its command line counterpart.

defaultpa2.png

Do the same for PaloAlto2:

defaultpa3.png

Configuring Palo Alto active-passive failover

Assign eth1/1 and eth1/2 for HA.

Network > Interfaces, then click on eth1/1

ha1.png

Then click on eth1/2 and select HA. The end result looks like below.

ha2.png

Then configure the HA configuration by clicking on Device > High Availability.

ha3.png

Click on the “gear” icon on Setup.

ha4.png

Set to group 1, both peers must be in the same group.

ha5

The default HA1 port is management port, however for this scenario the port has to be changed to eth1/1, and eth1/2 will be the backup port.

ha6

ha7.png

ha8

ha9.png

I want PaloAlto1 to be the active firewall in the HA setup, lower priority wins the active election, if both firewall has the same priority the lowest mac address will be elected.

ha10

ha11.png

Similar steps will be applied for PaloAlto2, there are some slight difference like the HA1 and its backup ip address and the election settings priority will be the default. Preemptive have to be enabled on active and passive firewall for the active role take over.

ha12.png

ha13.png

We can verify the HA configuration by going to the Dashboard and enabled the high availability widget.

ha14

ha15.png

ha16ha17

As shown above the HA has been successful.

 

Setting up routing for PaloAlto1 and 2

The configuration is done only on PaloAlto1 which is the active firewall.

Define which interfaces are layer3.

Network > Virtual Routers

vr1

Before creating the virtual router, you need to assign interfaces as Layer3.

eth1-3.png

eth1-4.png

eth1.png

eth1-4-1.png

Select eth1/3 and create subinterface for vlan 100. This subinterface will be the gateway for vlan 100. Vlan 100 is the transit network.

eth1-3-1

eth1-3-2.png

eth1-3-3.png

network1.png

Create a virtual router, add the layer3 interfaces assigned just now.

add interfaces.png

We need two static routes, 1st is a default route going towards internet and the other south-bound towards Win8.

 

vr3.png

 

vr5.png

vr7a.png

vr7n.png

 

 

 

 

 

 

Defining zones

Make eth1/3 as intranet and eth1/4 as internet zones.

zones1.png

 

zones3.png

zones5.png

 

Set up NAT for 192.168.x.x to go to internet

Click on Policies and NAT.

nat2

nat3.png

nat4.png

nat5.png

Commit the entire changes.

commit1.png

Posted in General stuffs | Leave a comment

BGP attributes: Weight

weight1

Facts about BGP weight attribute

  1. Cisco proprietary. Only available for Cisco routers, this attribute is not included in BGP update message.
  2. Because it is not included in update message, this attribute is only locally significant to one router.
  3. Because it is locally significant and only the configured router knows the weight, it is only viable for a Cisco router with more than one link peering to different BGP neighbors.
  4. This attribute is used to influence OUTBOUND traffic from the configured Cisco router. Higher weight is preferred.
  5. Weight attribute is the first attribute for Cisco router to “consider” for best BGP paths.
  6. Weight is applied to the inbound BGP routing updates in order to influence the OUTBOUND traffic.

Original BGP before weight is configured


R1#sh ip bgp | b Net
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 0.0.0.0 0 32768 i
* 22.22.22.0/24 192.168.13.3 0 2 i
*> 192.168.12.2 0 0 2 i
* 33.33.33.0/24 192.168.13.3 0 0 2 i
*> 192.168.12.2 0 2 i
*> 192.168.12.0/27 0.0.0.0 0 32768 i
*> 192.168.13.0/27 0.0.0.0 0 32768 i
R1#

weight2.png

So to reach 22.22.22.0/24 and 33.33.33.0/24 R1 will use R2, it is sensible for R1 to reach 22.22.22.0/24 via R2 since this prefix is a directly connected network for R2.

33.33.33.0/24 however is best reach via R3; this prefix is a directly connected network of R3.

Influence outbound traffic using weight on a neighbor


R1(config)#router bgp 1
R1(config-router)#neighbor 192.168.13.3 weight 500

So what happens?

weight3.png

-_-” duh…. this is not what I want… I want 22.22.22.0/24 via R2 and 33.33.33.0/24 via R3. So applying weight on neighbors is not viable in this requirement.

Use route-map for more granularity on selecting outbound path with weight


R1(config)#access-list 33 permit 33.33.33.0 0.0.0.255
R1(config)#route-map R1->33 permit 10
R1(config-route-map)#match ip address 33
R1(config-route-map)#set weight 500
R1(config-route-map)#route-map R1->33 permit 20
R1(config-route-map)#set weight 0
R1(config-route-map)#router bgp 1
R1(config-router)#neighbor 192.168.13.3 route-map R3->33 in

weight4.png

Using route-map is more granular, base on prefix i can choose which path to reach by using route-map with weight attribute.

Posted in BGP, Route | Tagged , , | Leave a comment

Is full meshed iBGP necessary?

bgp1

Revisit the configuration of the iBGP routers


R2#sh run | s r b
router bgp 2
bgp log-neighbor-changes
neighbor 3.3.3.3 remote-as 2
neighbor 3.3.3.3 update-source Loopback2
neighbor 3.3.3.3 next-hop-self
neighbor 4.4.4.4 remote-as 2
neighbor 4.4.4.4 update-source Loopback2
neighbor 4.4.4.4 next-hop-self
neighbor 192.168.12.1 remote-as 1
R2#
R3#sh run | s r b
router bgp 2
bgp log-neighbor-changes
neighbor 2.2.2.2 remote-as 2
neighbor 2.2.2.2 update-source Loopback3
neighbor 4.4.4.4 remote-as 2
neighbor 4.4.4.4 update-source Loopback3
R3#
R4#sh run | s r b
router bgp 2
bgp log-neighbor-changes
network 192.168.45.0
neighbor 2.2.2.2 remote-as 2
neighbor 2.2.2.2 update-source Loopback4
neighbor 2.2.2.2 next-hop-self
neighbor 3.3.3.3 remote-as 2
neighbor 3.3.3.3 update-source Loopback4
neighbor 3.3.3.3 next-hop-self
neighbor 192.168.45.5 remote-as 3
R4#

Full meshed iBGP

From the config R2 peers with R3 and R4. R3 peers with R2 and R4. R4 peers with R2 and R3, which logically looks like this.

full meshed.png

This is known as full meshed (logically), each iBGP router needs to peer with every iBGP routers within the same Autonomous System (AS).

What if not fully meshed?

full meshed2.png

If iBGP routers are not fully meshed to one another will it work?

Before I removed the peering, let’s revisit the BGP routing table of R2, R3 and R4.


R2#sh ip route bgp | beg Gate
Gateway of last resort is not set


5.0.0.0/32 is subnetted, 1 subnets
B 5.5.5.5 [200/0] via 4.4.4.4, 00:13:34
B 192.168.45.0/24 [200/0] via 4.4.4.4, 00:13:34
R2#
R3#sh ip route bgp | b Gate
Gateway of last resort is not set

5.0.0.0/32 is subnetted, 1 subnets
B 5.5.5.5 [200/0] via 4.4.4.4, 00:21:45
B 192.168.12.0/24 [200/0] via 2.2.2.2, 00:03:47
B 192.168.45.0/24 [200/0] via 4.4.4.4, 00:21:45
R3#
R4#sh ip route bgp | b Gate
Gateway of last resort is not set

5.0.0.0/32 is subnetted, 1 subnets
B 5.5.5.5 [20/0] via 192.168.45.5, 00:22:49
B 192.168.12.0/24 [200/0] via 2.2.2.2, 00:04:09
R4#

I removed the peering between R2 and R4.

R2(config)#router bgp 2
R2(config-router)#no neighbor 4.4.4.4
R2(config-router)#
R4(config)#router bgp 2
R4(config-router)#no neighbor 2.2.2.2
R4(config-router)#end
R4#

Let’s see the BGP tables on R2, R3 and R4.

R2#sh ip bgp | b Net
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.0/27 192.168.12.1 0 0 1 i
*> 192.168.12.0 0.0.0.0 0 32768 i
R2#
R3#sh ip bgp | b Net
Network Next Hop Metric LocPrf Weight Path
*>i 1.1.1.0/27 2.2.2.2 0 100 0 1 i
*>i 5.5.5.5/32 4.4.4.4 0 100 0 3 i
*>i 192.168.12.0 2.2.2.2 0 100 0 i
*>i 192.168.45.0 4.4.4.4 0 100 0 i
R3#
R4#sh ip bgp | b Net
Network Next Hop Metric LocPrf Weight Path
*> 5.5.5.5/32 192.168.45.5 0 0 3 i
*> 192.168.45.0 0.0.0.0 0 32768 i
R4#

R2 has lost the update on how to go to 5.5.5.5/32 and 192.168.45.0/24.
R4 has lost the update on how to go to 1.1.1.0/27 and 192.168.12.0/24.
Only R3 which is peered to R2 and R4 has all the paths known, R3 however does not share what was learned from R4 to R2 and vice versa.

This is known as BGP split horizon; in iBGP an iBGP router does not share prefixes learned from one iBGP router with another iBGP router.

Between different ASes, eBGP does routing loop prevention by using AS_PATH attribute, an eBGP router drops the prefix if it sees its own AS number within the prefix update. In iBGP the AS is unchanged, hence the BGP split horizon is the mechanism to ensure there is no routing loop among iBGP routers.

 

Posted in Route | Tagged , , , , | Leave a comment

IP routing with BGP

bgp1.png

Problem 1: Did not receive prefix advertised by BGP peer.

R2#sh ip bgp summary
BGP router identifier 2.2.2.2, local AS number 2
BGP table version is 1, main routing table version 1


Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
192.168.12.1 4 1 44 43 1 0 0 00:36:08 0

R2 did not receive prefix advertised by R1 via BGP.


R1#sh run | sec router bgp
router bgp 1
bgp log-neighbor-changes
network 1.1.1.1 mask 255.255.255.255
neighbor 192.168.12.2 remote-as 2
R1#


R1#sh ip route | begin Gate
Gateway of last resort is not set


1.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 1.1.1.0/27 is directly connected, Loopback1
L 1.1.1.1/32 is directly connected, Loopback1
192.168.12.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.12.0/24 is directly connected, Ethernet0/0
L 192.168.12.1/32 is directly connected, Ethernet0/0
R1#

This is due to incorrect subnet mask defined in router bgp. When you advertised prefix in BGP the subnet mask must be exactly matched.

R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#router bgp 1
R1(config-router)#no network 1.1.1.1 mask 255.255.255.255
R1(config-router)#network 1.1.1.0 mask 255.255.255.224
R1(config-router)#

Let’s verify R2’s BGP status


R2>sh ip bgp summary
BGP router identifier 2.2.2.2, local AS number 2
BGP table version is 2, main routing table version 2
1 network entries using 144 bytes of memory
1 path entries using 80 bytes of memory
1/1 BGP path/bestpath attribute entries using 152 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 400 total bytes of memory
BGP activity 1/0 prefixes, 1/0 paths, scan interval 60 secs

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
192.168.12.1 4 1 64 62 2 0 0 00:53:23 1
R2>


R2>sh ip bgp
BGP table version is 2, 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,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.0/27 192.168.12.1 0 0 1 i
R2>

The best path is selected and installed into routing table

R2>sh ip route bgp | begin Gate
Gateway of last resort is not set

1.0.0.0/27 is subnetted, 1 subnets
B 1.1.1.0 [20/0] via 192.168.12.1, 00:01:58
R2>

Problem 2: R1 and R5 could not see routes advertised in BGP

R1 could not get the routes advertised by R5 (5.5.5.5/32) and R5 could not get the routes advertised by R1 (1.1.1.0/27).

The problem is that only R1 and R2 have formed BGP peers and shared routes advertised by R1, and R4 and R5 have formed BGP peers and shared routes advertised by R5. There is no internal BGP (iBGP) formed between R2 and R4.

iBGP is necessary for route advertised by eBGP to transit from one Autonomous System (AS) to another AS.

R2(config)#router bgp 2
R2(config-router)#neighbor 4.4.4.4 remote-as 2
R2(config-router)#neighbor 4.4.4.4 update-source lo2
R4(config)#router bgp 2
R4(config-router)#neighbor 2.2.2.2 remote
R4(config-router)#neighbor 2.2.2.2 remote-as 2
R4(config-router)#neighbor 2.2.2.2 update-source lo4
R4(config-router)#end


R2#sh ip bgp summary | in Nei|4.4.4.4
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
4.4.4.4 4 2 18 18 2 0 0 00:12:06 1
R2#
R4#sh ip bgp summary | in Neig|2.2.2.2
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2.2.2.2 4 2 19 19 2 0 0 00:12:56 1
R4#

As can be seen the neighborship is formed and prefix is shared.

Problem 2.1: BGP routes not in routing table

Although R2 and R4 have formed iBGP neighbors and provides means to let the prefix advertised to be received as shown in show ip bgp summary command. R1 and R5 still do not have routes of each other in their own routing table.

R2 and R4 also do not have 5.5.5.5 and 1.1.1.1 found in their own routing table respectively.


R2#sh ip bgp | begin Net
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.0/27 192.168.12.1 0 0 1 i
* i 5.5.5.5/32 192.168.45.5 0 100 0 3 i
R2#

Although 5.5.5.5/32 is received by R2 it is not put into its routing table, a router only puts the best route into its own routing table.

As shown in the show ip bgp command the next hop to reach 5.5.5.5 is via 192.168.45.5, but R2 has no knowledge of this route!

R2#sh ip route 192.168.45.5
% Network not in table
R2#

The situation is the same for R4

R4#sh ip bgp | beg Net
Network Next Hop Metric LocPrf Weight Path
* i 1.1.1.0/27 192.168.12.1 0 100 0 1 i
*> 5.5.5.5/32 192.168.45.5 0 0 3 i
R4#

R4 does not know how to reach 192.168.12.1 and hence 1.1.1.0/27 prefix though is received, is not installed into its own routing table.

R4#sh ip route 192.168.12.1
% Network not in table
R4#

The solution can be R2 advertise 192.168.12.2 via OSPF and R4 advertise 192.168.45.4 via OSPF

R2(config)#router ospf 1
R2(config-router)#network 192.168.12.2 0.0.0.0 area 0
R2(config-router)#end
R4(config)#router ospf 1
R4(config-router)#network 192.168.45.4 0.0.0.0 area 0

Or to use the bgp neighbor x.x.x.x next-hop-self command.

R2(config)#router bgp 2
R2(config-router)#neighbor 4.4.4.4 next-hop-self
R2(config-router)#end
R4(config-router)#router bgp 2
R4(config-router)#neighbor 2.2.2.2 next-hop-self

BGP does not change the next hop by default.


R2#sh ip bgp | in Net|5.5.5.5
Network Next Hop Metric LocPrf Weight Path
*>i 5.5.5.5/32 4.4.4.4 0 100 0 3 i
R2#sh ip route bgp | beg Gate|5.5.5.5
Gateway of last resort is not set

1.0.0.0/27 is subnetted, 1 subnets
B 1.1.1.0 [20/0] via 192.168.12.1, 02:33:04
5.0.0.0/32 is subnetted, 1 subnets
B 5.5.5.5 [200/0] via 4.4.4.4, 00:03:15
R2#
R4#sh ip bgp | in Net|1.1.1.
Network Next Hop Metric LocPrf Weight Path
*>i 1.1.1.0/27 2.2.2.2 0 100 0 1 i
R4#show ip route bgp | beg Gate
Gateway of last resort is not set

1.0.0.0/27 is subnetted, 1 subnets
B 1.1.1.0 [200/0] via 2.2.2.2, 00:06:26
5.0.0.0/32 is subnetted, 1 subnets
B 5.5.5.5 [20/0] via 192.168.45.5, 02:39:22
R4#

As shown above the next hop address to reach 1.1.1.0/27 and 5.5.5.5/32 are updated.

Now the R1 and R5 should have the each other’s advertised routes.

R1>sh ip route bgp | beg Gate
Gateway of last resort is not set


5.0.0.0/32 is subnetted, 1 subnets
B 5.5.5.5 [20/0] via 192.168.12.2, 00:05:41
R5>sh ip route bgp | beg Gate
Gateway of last resort is not set

1.0.0.0/27 is subnetted, 1 subnets
B 1.1.1.0 [20/0] via 192.168.45.4, 00:08:52
R5>

Problem 3: R1 and R5 could not reach each other’s advertised prefix

R1>sh ip route bgp | beg Gate
Gateway of last resort is not set

5.0.0.0/32 is subnetted, 1 subnets
B 5.5.5.5 [20/0] via 192.168.12.2, 00:05:41
R1>ping 5.5.5.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.5.5.5, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R1>
R5>sh ip route bgp | beg Gate
Gateway of last resort is not set

1.0.0.0/27 is subnetted, 1 subnets
B 1.1.1.0 [20/0] via 192.168.45.4, 00:08:52
R5>ping 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R5>

Let’s traceroute and see which router has dropped the traffic.

R1#traceroute 5.5.5.5 numeric
Type escape sequence to abort.
Tracing the route to 5.5.5.5
VRF info: (vrf in name/id, vrf out name/id)
1 192.168.12.2 1 msec 0 msec 1 msec
2 * * *
3
R1#

The problem is with R3!


R3#sh ip route | beg Gate
Gateway of last resort is not set

2.0.0.0/32 is subnetted, 1 subnets
O 2.2.2.2 [110/11] via 192.168.23.2, 03:30:14, Ethernet0/1
3.0.0.0/32 is subnetted, 1 subnets
C 3.3.3.3 is directly connected, Loopback3
4.0.0.0/32 is subnetted, 1 subnets
O 4.4.4.4 [110/11] via 192.168.34.4, 03:27:50, Ethernet0/2
192.168.23.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.23.0/24 is directly connected, Ethernet0/1
L 192.168.23.3/32 is directly connected, Ethernet0/1
192.168.34.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.34.0/24 is directly connected, Ethernet0/2
L 192.168.34.3/32 is directly connected, Ethernet0/2
R3#

R3 has no idea where to route 1.1.1.1 or 5.5.5.5 because these two networks not in its routing table.

Two solutions:

  1. Redistribute BGP into OSPF; 1 prefix is fine… but if there are 600k prefixes then I think R3 cannot take it!
  2. Make R3 to be iBGP as well! Talk the same language buddy!


R3(config)#router bgp 2
R3(config-router)#neighbor 2.2.2.2 remote-as 2
R3(config-router)#neighbor 2.2.2.2 update-source lo3
R3(config-router)#neighbor 4.4.4.4 remote-as 2
R3(config-router)#neighbor 4.4.4.4 update-source lo3
R3(config-router)#end
R2(config)#router bgp 2
R2(config-router)#neighbor 3.3.3.3 remote-as 2
R2(config-router)#neighbor 3.3.3.3 update-source lo2
R2(config-router)#neighbor 3.3.3.3 next-hop-self
R2(config-router)#end
R4(config)#router bgp 2
R4(config-router)#neighbor 3.3.3.3 remote-as 2
R4(config-router)#neighbor 3.3.3.3 update-source lo4
R4(config-router)#neighbor 3.3.3.3 next-hop-self
R4(config-router)#end


R3#sh ip bgp | beg Net
Network Next Hop Metric LocPrf Weight Path
*>i 1.1.1.0/27 2.2.2.2 0 100 0 1 i
*>i 5.5.5.5/32 4.4.4.4 0 100 0 3 i
R3#sh ip route bgp | beg Gate
Gateway of last resort is not set

1.0.0.0/27 is subnetted, 1 subnets
B 1.1.1.0 [200/0] via 2.2.2.2, 00:01:30
5.0.0.0/32 is subnetted, 1 subnets
B 5.5.5.5 [200/0] via 4.4.4.4, 00:01:30
R3#

So I think R1 should be able to reach 5.5.5.5 and R5 to reach 1.1.1.1?

R1>ping 5.5.5.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.5.5.5, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R1>
R5>ping 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R5>

HUH?!

Problem 4: R1 and R5 cannot reach each other’s advertised prefix despite via transit AS that has all iBGP routers.

I turn on debug ip packet on R1 and R5; Found something interesting on R1’s debug.

R1#
*Sep 10 14:22:50.160: IP: tableid=0, s=192.168.45.5 (Ethernet0/0), d=1.1.1.1 (Loopback1), routed via RIB
*Sep 10 14:22:50.160: IP: s=192.168.12.1 (local), d=192.168.45.5, len 56, unroutable
R1#u all
All possible debugging has been turned off
R1#

It says 192.168.45.5 is unroutable!


R5#sh ip route | b Ga
Gateway of last resort is not set

1.0.0.0/27 is subnetted, 1 subnets
B 1.1.1.0 [20/0] via 192.168.45.4, 01:04:37
5.0.0.0/32 is subnetted, 1 subnets
C 5.5.5.5 is directly connected, Loopback5
192.168.45.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.45.0/24 is directly connected, Ethernet0/0
L 192.168.45.5/32 is directly connected, Ethernet0/0
R5#
R5#sh run | s r b
router bgp 3
bgp log-neighbor-changes
network 5.5.5.5 mask 255.255.255.255
neighbor 192.168.45.4 remote-as 2
R5#

So let’s try advertise 192.168.45.0/24 via BGP on R4?

R4(config)#router bgp 2
R4(config-router)#network 192.168.45.0 mask 255.255.255.0
R4(config-router)#end

Also from R5’s debug:

R5#
*Sep 10 14:28:09.544: IP: tableid=0, s=192.168.12.1 (Ethernet0/0), d=5.5.5.5 (Loopback5), routed via RIB
*Sep 10 14:28:09.544: IP: s=192.168.12.1 (Ethernet0/0), d=5.5.5.5, len 100, rcvd 4
*Sep 10 14:28:09.544: IP: s=192.168.12.1 (Ethernet0/0), d=5.5.5.5, len 100, stop process pak for forus packet
*Sep 10 14:28:09.544: IP: s=5.5.5.5 (local), d=192.168.12.1, len 100, unroutable
R5#

the network 192.168.12.0/24 also unreachable, so let’s advertise the 192.168.21.0/24 route on R2

R2(config)#router bgp 2
R2(config-router)#network 192.168.12.0 mask 255.255.255.0
R2(config-router)#end

Finally!

R1#ping 5.5.5.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.5.5.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/3 ms
R1#
R1#sh ip bgp | beg Net
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.0/27 0.0.0.0 0 32768 i
*> 5.5.5.5/32 192.168.12.2 0 2 3 i
r> 192.168.12.0 192.168.12.2 0 0 2 i
*> 192.168.45.0 192.168.12.2 0 2 i
R5#ping 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
R5#


R5#sh ip bgp | beg Net
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.0/27 192.168.45.4 0 2 1 i
*> 5.5.5.5/32 0.0.0.0 0 32768 i
*> 192.168.12.0 192.168.45.4 0 2 i
r> 192.168.45.0 192.168.45.4 0 0 2 i
R5#

Posted in BGP, Route | Tagged | Leave a comment

Solving routing loop problem due to poorly configured redistribution

The diagram

routing-loops

Routing loop when vIOS2 (R2) is trying to reach 1.1.1.1 in vIOS1 (R1)


R2#traceroute 1.1.1.1 numeric
Type escape sequence to abort.
Tracing the route to 1.1.1.1
VRF info: (vrf in name/id, vrf out name/id)
1 192.168.23.3 4 msec 4 msec 5 msec
2 192.168.34.4 4 msec 8 msec 5 msec
3 192.168.24.2 2 msec 4 msec 3 msec
4 192.168.23.3 10 msec 6 msec 4 msec
5 192.168.34.4 7 msec 8 msec 6 msec
6 192.168.24.2 7 msec 6 msec 6 msec
7 192.168.23.3 9 msec 7 msec 7 msec
8 192.168.34.4 9 msec 8 msec 11 msec
9 192.168.24.2 8 msec 8 msec 10 msec
10 192.168.23.3 14 msec 9 msec 10 msec
11 192.168.34.4 12 msec 13 msec 12 msec
12 192.168.24.2 11 msec 9 msec 11 msec
13 192.168.23.3 12 msec 11 msec 14 msec
14 192.168.34.4 16 msec 13 msec 11 msec
15 192.168.24.2 10 msec 13 msec 11 msec
16 192.168.23.3 13 msec 14 msec 7 msec
17 192.168.34.4 16 msec 18 msec 10 msec
18 192.168.24.2 12 msec 14 msec 13 msec
19 192.168.23.3 14 msec 15 msec 12 msec
20 192.168.34.4 13 msec 18 msec 19 msec
21 192.168.24.2 19 msec 18 msec 18 msec
22 192.168.23.3 16 msec 16 msec 14 msec
23 192.168.34.4 17 msec 17 msec 16 msec
24 192.168.24.2 17 msec 20 msec 17 msec
25 192.168.23.3 20 msec 23 msec 19 msec
26 192.168.34.4 24 msec 24 msec 18 msec
27 192.168.24.2 20 msec 17 msec 18 msec
28 192.168.23.3 19 msec 23 msec 19 msec
29 192.168.34.4 21 msec 23 msec 23 msec
30 192.168.24.2 22 msec 29 msec 18 msec
R2#

Route tagging

The logic is not to redistribute prefix that is tagged, if the prefix is not tag; tag it.

R3(config)#route-map distribution-tag deny 1
R3(config-route-map)#match tag 666
R3(config-route-map)#exit
R3(config)#route-map distribution-tag permit 2
R3(config-route-map)#set tag 666
R3(config-route-map)#exit
R3(config)#router rip
R3(config-router)#redistribute ospf 1 metric 1 route-map distribution-tag
R3(config-router)#router ospf 1
R3(config-router)#redistribute rip subnets route-map distribution-tag
R3(config-router)#end


R4#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R4(config)#route-map distribution-tag deny 1
R4(config-route-map)#match tag 666
R4(config-route-map)#exit
R4(config)#route-map distribution-tag permit 2
R4(config-route-map)#set tag 666
R4(config-route-map)#exit
R4(config)#router rip
R4(config-router)#redistribute ospf 1 metric 1 route-map distribution-tag
R4(config-router)#exit
R4(config)#router ospf 1
R4(config-router)#redistribute rip subnets route-map distribution-tag

Traceroute


R2#traceroute 1.1.1.1 numeric
Type escape sequence to abort.
Tracing the route to 1.1.1.1
VRF info: (vrf in name/id, vrf out name/id)
1 192.168.12.1 4 msec * 6 msec
R2#

Posted in Route | Tagged , , | Leave a comment

Administrative distance

Administrative distance (AD) influences the decision on which routing protocol the router should trust:

  1. AD can be modified.
  2. AD is only locally significant to the router, other router’s AD of routing protocol might be modified.
  3. Router will use the routing protocol that has the lowest AD to make routing decision.

Default Administrative distance of various routing protocols:

Directly connected = 0

Static route = 1

EIGRP summary = 5

External BGP (eBGP) = 20

EIGRP = 90

IGRP = 100 (Still exists?)

OSPF = 110

IS-IS = 115

RIP = 120

On Demand Routing (ODR) = 160

External EIGRP = 170

Internal BGP (iBGP) = 200

Unknown = 255

 

 

Posted in Route | Tagged | Leave a comment

Classless routing vs classful routing

Router routes traffic based on the longest prefix, and cannot find any match traffic will be dropped.

Classless routing

The routing that we normally understand is classless routing.

Let’s explore the routing tables of R1 and R2.

R1_1

R2_1

R1_2.png

R1 pings to 10.10.10.2 because a specific static route 10.10.10.2 is in the routing table

R1_3.png

R1 can ping to the above two addresses because the default route is matched. So classless routing is this:

  1. Find the route with the longest prefix.
  2. If there is no match in the longest prefix it will match the default route

Classful routing

R1_4.png

ip classless is turned on by default. To demonstrate classful routing we need to turn off ip classless and ip cef.

R1_1

Let’s revisit R1’s routing table. With classful routing, routing decision changes.

R1_5.png

No problem with 10.10.10.2 because there is a specific match in the routing table.

No problem with 172.30.1.1 because there is no big networks 172.30.x.x in the routing table and it matches the default route.

Problem with 192.168.1.33, because there is a big network which says:

192.168.1.0/24 is variably subnetted, 4 subnets, 3 masks.

Now 192.168.1.33 is under 192.168.1.0/24 and because there is no specific route and it matches the big network the traffic is dropped due to no match is found. Router will not look into the default route when there is no match for 192.168.1.0/24.

R1_6.png

From the debug it says 192.168.1.33 is unroutable. In this scenario specific route to 192.168.1.33 has to be added to the routing table.

R1_7.png

So classful routing:

  1. matches route with the longest prefix same as the classless routing.
  2. if there is a big network, and there is no specific route to this big network the traffic is drop.
  3. If there is no longest prefix route, and the address is not under any big network then router consults the default route.
Posted in General stuffs, Route | Tagged , , | Leave a comment