Entries Tagged as ''

BGP Neighbor Features in One Shot

The water in BGP is deep, I should say. However, to make our world simpler, we may summarize our knowledge by one screen shot. For example, to learn BGP neighbor features, we can simply see what options besides neighbor commands. Let’s take a screen shot first.

picture-1

I can safely say that, each commands can be one section on the book or tutorials.

  • For example, we can change EBGP default TTL=1 to 255 by issue ebgp-multihop command. We also can restrict neighbor hop count by issue ttl-security command.
  • allowas-in will be last resort for some AS is partitioned, but it may cause count-to-infinity problem if hop-count is larger.
  • when we issue send-community, then we know what’s well-known four communities are.
  • local-as is tell neighbor that advertised routes are originated by using this AS number. The AS number will be preapended on the real AS.
  • next-hop-self is useful when advertising route to iBGP but the neighbor doesn’t have the route on IGP table. If the iBGP neighbor doesn’t change next-hop value, then it has no way to know how to get that route. next-hop-unchange is useful to solve loop problem when eBGP neighbor set next hop to me and the actual route has to bypass this neighbor.
  • max-prefix is another security feature which only allows certain number of TCP session up.
  • soft-reconfiguration is good feature to ask neighbor re-advertise route without tear down and resetup TCP session. It’s more like command “clear ip bgp * soft“.
  • etc…

EIGRP Stub Routing

The detailed EIGRP Stub Routing is introduced in here. I couldn’t describe this better than that. :)

However, I do have my thinking for this feature and will present in here.

EIGRP Stub routing is basic idea to slove EIGRP stuck in active problem. It’s easy to illustrate in hub-and-spoke network that hub connects to WAN and all spokes have to go pass through hub to the outside world. So, the hub router doesn’t need to send QUERY to all spoke when WAN network changed. To enable “eigrp stub” on EIGRP process, hub router will not send QUERY to spokes.

We can do a simple testing for this feature. As we can see from diagram, R2 is a distribution router as hub and R3 is a access router as a spoke. R1 will be some router outside.

R1 <——–VLAN432—————-> R2 (Hub)<—————VLAN450——————-> R3 (Spoke)

When eigrp stub disabled on R3, we can do “debug eigrp package query“. We can see that R2 send QUERY to both VLAN432 and VLAN450.

23:02:06: EIGRP: Received QUERY on Vlan432 nbr 10.2.106.81
23:02:06:   AS 10, Flags 0×0, Seq 21/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely0
23:02:06: EIGRP: Enqueueing QUERY on Vlan450 iidbQ un/rely 0/1 serno 33-48
23:02:06: EIGRP: Enqueueing QUERY on Vlan432 iidbQ un/rely 0/1 serno 33-48
23:02:06: EIGRP: Sending QUERY on Vlan450
23:02:06:   AS 10, Flags 0×0, Seq 33/0 idbQ 0/0 iidbQ un/rely 0/0 serno 33-48
23:02:06: EIGRP: Sending QUERY on Vlan432
23:02:06:   AS 10, Flags 0×0, Seq 34/0 idbQ 0/0 iidbQ un/rely 0/0 serno 33-48

When eigrp stub is enabled, we can see that R2 will NOT send QUERY to vlan450 anymore. But it still send QUERY to VLAN432.

23:03:07: EIGRP: Received QUERY on Vlan432 nbr 10.2.106.81
23:03:07:   AS 10, Flags 0×0, Seq 24/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely0
23:03:07: EIGRP: Enqueueing QUERY on Vlan450 iidbQ un/rely 0/1 serno 81-96
23:03:07: EIGRP: Enqueueing QUERY on Vlan432 iidbQ un/rely 0/1 serno 81-96
23:03:07: EIGRP: Sending QUERY on Vlan432
23:03:07:   AS 10, Flags 0×0, Seq 40/0 idbQ 0/0 iidbQ un/rely 0/0 serno 81-96
23:03:10: EIGRP: Received QUERY on Vlan450 nbr 192.168.50.92
23:03:10:   AS 10, Flags 0×0, Seq 20/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely0

BGP Route Reflector Roles

BGP Route Reflector normally has three kinds of peers

  • EBGP Peer
  • Client Peer ( neighbor 1.2.3.4 route-reflect-client )
  • Non-client Peer ( no neighbor 1.2.3.4 route-reflect-client)

Route Reflector can learn from or advertise to all three kinds of peers. However, non-client peer can NOT learn from or advertise to non-client peer. As we can see from the following diagram, Since R3 is non-client, it can NOT advertise route to R4, which is also non-client peer.

BGP RR diagram 1There are two ways to solve this problem.(Of course, many ways can be done to implement this.)

One is to make R3 as Client Peer. Since R3 is Client Peer, it will advertise route to R4.

BGP RR Diagram 2The other is, we make R3 as another RR and make R4 and R2 as Client Peer. If we don’t make R2 as R3’s Client Peer, R2 is non-client peer with R3. Since R3 is RR, R3 is non-client peer with R2. If R3 has no neighbor relationship with R1, then two non-client peer can NOT advertise to each other. Therefore, we make R2 as Client Peer with R3.

BGP RR Diagram 3

OSPF Summarization

Briefly outline in here that OSPF has two ways to do summarization

For Internal Area: area <#> range <IP> <Mask>

The summarization has to be done on ABR. It actually said that, for area <#>, we are going to summary as this IP with this Mask and advertise it out by default. The summarization will be advertised as LSA Type 3 to the whole areas. The summarization will not suppress sub network, which is different with summary-address in OSPF and ip summary-address in RIP and EIGRP.

For External Area: summary-address <IP> <Mask>

The summarization has to be done on ASBR. (This command will do nothing if configured on ABR). It actually said that, all external route can be summrized as <IP> with <Mask>. It will be advertised to all OSPF area as LSA type 5. The advertising router is ASBR for the whole area, and most important, it will advertise back to IGP like RIP or EIGRP when doing mutual redistribution, since it will generate a discard route in the local routing table – “O    10.10.0.0/21 is a summary, 18:32:09, Null0″. The redistribution from OSPF to RIP, as an example, will do two steps.

  1. show ip route ospf to see all OSPF generated route.
  2. list all connected interface that advertised by OSPF

Therefore, we need route-map when advertise OSPF to RIP or EIGRP to filter out this summary route.

NBMA Mode and GRE Tunnel on IP Multicast

There are two interesting topics in IP Multicast network to solve problem on Frame Relay network. Frame relay network is non-broadcast media access network type. However, it can perform “pseudo-broadcast” and performed at router’s CPU level. Frame relay network is also hub-spoke network type. So, here are two problems.

  1. Since IP multicast is perform RPF calcuation, how one spoke send multicast traffic to another spoke?
  2. If multicast source is on the top of Hub, since OIL (outgoing interface list) is only one serial interface, how the traffic is going to only the spoke which required multicast traffic, in stead of all spokes?

ip nbma-mode is one of the solutions. First, NBMA mode is ONLY working on PIM sparse mode. Second, if one serial interface enable NBMA mode, it automatically change OIL to the spoke IP address, not outgoing interface anymore. Thus, The traffic can only go to that spoke.

GRE tunnel is another way to solve spoke traffic to another spoke.

GRE Tunnel in Multicast

We can see from diagram above that, R4 is MA (Mapping Agent), R4 will advertise RP information to all 224.0.1.40 by using PIM dense mode. Remeber, Auto-RP is communicated by using PIM Dense Mode. RP will send advertised to 224.0.1.39, which is listened by MA. Then, MA send advertisement to all 224.0.1.40. The traffic will never go to R1 even though NBMA mode is enabled on R5. So, we need create a GRE tunnel between R4 and R1.

R4

interface tunnnel 0

tunnel source loopback 0

tunnel destination 150.1.1.1

ip unnumber loopback 0

ip pim sparse-mode

R1

interface tunnel 0

tunnel source loopback 0

tunnel destination 150.1.4.4

ip unnumber loopback 0

ip pim sparse-mode

However, when show ip pim rp mapping on R1, there is no RP shown. This is because RPF failure. When we show ip route 150.1.4.4 on R1, it point to serial interface, but Mapping Agenet is learned from tunnel interface. So, we need add a static mroute on the global.

ip mroute 150.1.4.4 255.255.255.255 tunnel 0

Getting Transit Packets on Router

If we use debug ip packet on Cisco router, we can only see the packets that originated on the router or destinated to the router. We cannot see any transit packets. The reason is, in the interface level, the command ip route-cache is enabled as default. We can define route-cache options to NetFlow or CEF. On the most cases, route-cache is using CEF because ip cef is enabled on the global.

Therefore, we need to type no ip route-cache in interface level to let all transit IP packet to pass through processor.

NAT Pool IP Address Need Participate IGP

In the NAT world, there are two terminologies that we used often, one is Inside Local, and the other is Inside Global. Inside Local is those IP address hidden behind NAT. Inside Global is virtual IP address pool that can be accessed from outside world. Before configuring NAT, we need to define an access-list for INSIDE_LOCAL to define which IP address participate NAT process. We also need to define an IP pool for INSIDE_GLOBAL. Then, we can enable NAT

ip nat inside source list INSIDE_LOCAL pool INSIDE_GLOBAL overload

However, we still can’t ping outside from inside. Why? because INSIDE_GLOBAL are virtual IP addresses that outside routers don’t have route to it. To solve this problem, we have two options.

  1. Create a loopback interface, assign IP address to the interface and let it running IGP in outside network.
  2. Create a static route on NAT router and point it to Null0 interface. Redistribute the static route to IGP in outside network.

TCL Shell Ping on Cisco IOS

For testing purpose to know if every device in the network is reachable, we can use TCL shell on Cisco IOS. It does has been well documented, but it should be shown in my blog. :)

In global mode, we can type “tclsh” to enter to tclsh mode. Then, we type the script as following:

R1#tclsh
R1(tcl)#foreach address {
+>(tcl)#90.90.1.1
+>(tcl)#90.90.2.2
+>(tcl)#90.90.3.3
+>(tcl)#90.90.4.4
+>(tcl)#90.90.5.5
+>(tcl)#90.90.6.6
+>(tcl)#90.90.8.8
+>(tcl)#90.90.10.10 } { ping $address repeat 2 }

Type escape sequence to abort.
Sending 2, 100-byte ICMP Echos to 90.90.1.1, timeout is 2 seconds:
!!
Success rate is 100 percent (2/2), round-trip min/avg/max = 1/1/1 ms
Type escape sequence to abort.
Sending 2, 100-byte ICMP Echos to 90.90.2.2, timeout is 2 seconds:
!!

OSPF Filtering and Range Summary sequence

OSPF Type-3 LSA Filtering can be used to permit or deny any arbitrary inter-area routes based on a prefix-list. The filtering process is in ABR under router ospf process.

  • area <#> filter-list <name> [in | out]

Also, for reducing routing table in other area, sometimes we will summarize network.

  • area <#> range <IP> <MASK>

However, here is a question, under ospf process, filter before range summary or range summary before filter? We do a test by the following scenario.

The topology may like this:

<–AREA 1–> ABR <—-AREA 0–>

Aare 1 has three networks. We can see them by “show ip route”.

  • 172.18.12.0/24
  • 172.18.13.0/24
  • 172.18.15.0/24

We also can summarize those three network to one network and advertise to Area 0.

  • area 1 range 172.18.12.0 255.255.252.0

First, we need to generate a filtering list by prefix list. If we only create a prefix list as following, the summary route (discards route in local) will not generated and the summary route is not advertised out.

  • ip prefix-list A1->A0 seq 5 permit 172.18.12.0/22

Why?

Because prefixe list will check both bits and subnet mask. Both would have to match for the network to be either permitted or denied. In the above case, there is only a “/” after the network (no le or ge), then the number after the “/” is both bits checked and subnet mask. So it will check the 22 bits from left to right (won’t care about the last 10 bits) AND it will make sure that it has a 22 bit mask. BOTH the 22 bits checked and the 22 bit subnet mask must match for the network to be permitted or denied. However, the scenario doesn’t have 22 bit submask network in routing table. Therefore, there will be nothing to generated and advertise out. If we revise the ip prefix list like the following, then the summary route is advertised out.

  • ip prefix-list A1->A0 seq 5 permit 172.18.12.0/22 ge 24 le 24

Why?

Because if we use either the le or ge (or both le and ge) after the “/”, then the number directly after the “/” becomes only bits checked and the number after the ge or le (or both) is the subnet mask. So in this case we are still going to check the first 22 bits of the network from left to right. If those match we are then going to check the subnet mask, which in this case can be GREATER THAN OR EQUAL TO 24 bits – meaning that as long as the first 22 bits of the network match the subnet mask could be 25,26,27,28,29,30,31,or 32 bits. They would all match.

So, we can safely say that, OSPF do filtering before range summary.

Why Disable Peer Neighbor Route

When configure PPP over Frame Relay, we may observe that there are 32bit host route in both PPP link router, along with one 24bit subnet route. So, what’s the purpose of host route in PPP link? The peer neighbor route is used to provide reachability when both ends of the PPP link are not on the same logical subnet, or IP unnumbered. For example, on Router A, the interface virtual-template 1 IP is 10.10.10.1/24, on Router B, the interface virtural-template 1 IP is 192.168.100.1/24. Then, when PPP Link is up, Router A can ping Router B by using different subnet IP address successfully. However, if two Virtual-Template interface are in the same subnet, then we don’t need host route generated. So, we can sfely disable by “no peer neighbor-route” command under Virtual-Template interface.

Before disable, the routing table are as following:

Router A:

C       10.10.24.0/24 is directly connected, Virtual-Access2

C       10.10.24.4/32 is directly connected, Virtual-Access2

Router B:

C       10.10.24.0/24 is directly connected, Virtual-Access2
C       10.10.24.2/32 is directly connected, Virtual-Access2

After diable peer neigbor route, the routing table are as following:

Router A:

C       10.10.24.0/24 is directly connected, Virtual-Access2

Router B:

C       10.10.24.0/24 is directly connected, Virtual-Access2

Also, recall that how router does when forward a packet.

  1. Router look up the destination IP address and search on routing table by longest-matching approach.
  2. Router do Layer3 to Layer2 map searching for Ethernet or Frame Relay to get layer2 address, either MAC or DLCI, but not for PPP.
  3. Router finally encapsulate the pacckage and send out the interface in the forwarding table.