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.

Title2Read

Reminder:

OSPF and IS-IS: Choosing an IGP for Large-Scale Networks

Cloud networking blog

I have come across very interesting blog about cloud networks:

http://networkheresy.com/


I wish I had enough time to read everything about networking that is interesting to me. I hardly find enough time to follow ioshints.

BGP Default Route

Another great article from Ivan Pepelnjak.

What was particularly interesting to me is the idea to check presence of specific routes in the routing table before advertising default route!

This kind of tracking can also be used to quickly close peering session with a neighboring BGP router. Imagine we have a host route to a BGP peer loopback that is advertised, for example, via OSPF. We can match this route with a prefix-list and then use it in a route-map to create a condition for a BGP session closing. This described in a great detail in Designing Fast Converging BGP Networks.

Frame-relay Inverse-ARP caveats

Hello, long time no see!
Today I have come across a very interesting examples of Inverse-ARP.

1

Suppose we have a "hub and spoke" topology where hub uses multipoint interface with the following configuration:

interface Serial0/0.200 multipoint
  ip address 155.1.200.5 255.255.255.0
  frame-relay interface-dlci 503
  frame-relay interface-dlci 504

 Spokes have the following config under their respective interfaces:

interface Serial1/0
  ip address 155.1.200.3 255.255.255.0
  encapsulation frame-relay
  frame-relay map ip 155.1.200.5 305 broadcast

This configuration is working. And the reason lies in the fact that "frame-relay map" command effectively disables Inverse-ARP on the particular DLCI, but it's important to understand that it disables only Inverse-ARP requests but not Inverse-ARP responses!

It means that "spoke" has static map to reach the "hub" that disable Inverse-ARP requests. However, it still replies to the requests coming from the "hub", so the "hub" will have dynamic mappings from Inverse-ARP!

2

Imagine that we have the exact same topology but now "spokes" have static mappings to reach each other, however static mapping to reach the "hub" has been removed.

interface Serial0/0.200 multipoint
  ip address 155.1.200.5 255.255.255.0
  frame-relay interface-dlci 503
  frame-relay interface-dlci 504

Spokes have the following config under their respective interfaces:
Spoke 1

interface Serial1/0
  ip address 155.1.200.3 255.255.255.0
  encapsulation frame-relay
  frame-relay map ip 155.1.200.4 305 broadcast

Spoke 2

interface Serial1/0
  ip address 155.1.200.4 255.255.255.0
  encapsulation frame-relay
  frame-relay map ip 155.1.200.3 405 broadcast

Since "spokes" use the same DLCI to reach "hub" and other "spokes" Inverse-ARP now can't be used to discover "hub's" IP to Layer-2 mapping. The interesting thing is that this configuration works because "hub" still sends Inverse-ARP requests and even though it's disabled on "spokes", they are still able to add dynamic mappings to reach "hub" (while responding to Inverse-ARP requests, spokes also add dynamic mappings to reach "hub")!




P.S. It wouldn't change anything if I added "no frame-relay inverse-arp" under the "spoke's" serial interfaces.
P.P.S. I hate Frame-Relay :D

Redistribution facts

1. When redistributing something (for example, EIGRP into BGP) with route-maps, changes in access-list that used to match specific routes, do not force new routes to automatically populate BGP table! For this to happen, we have to "no redistribute eigrp X ......" and then re-enter it!

More to come :)

Redistribution of static routes to EIGRP

I have learnt an interesting fact about redistribution into EIGRP process. If you want to redistribute static route as INTERNAL to EIGRP, you should use simple network x.x.x.x command instead of redistribute static. EIGRP treats static routes to interface as a connected networks, so it works pretty well!

eBGP connection issues

eBGP connections differ form iBGP connections in the way router with TTL value inside the IP packet. By default, BGP sends packets with TTL value set to 255 to it's iBGP peers, so if we are connecting to the loopback interface (or other IP addresses that are more than 1 hop away) everything works well out of the box. This is not the case for the eBGP peers. In order to connect to loopback interface of eBGP peer, we have to configure "neighbor x.x.x.x ebgp-multihop 'TTL value'" router command, because by default BGP sends packets with IP TTL set to 1! If you forgot to do this this, "show ip bgp summary" will show the neighbor connection sitting in IDLE state!

How to delete Local SR on XenServer

1. First, you have to determine the Storage-Repository-UUID:

xe sr-list 

2. Find the corresponding Physical Block Device (PBD):

xe pbd-list sr-uuid=your-SR-uuid

3. Unplug the PBD:

xe pbd-unplug uuid=your-PBD-uuid

4. Delete PBD:

xe pbd-destroy uuid=your-PBD-uuid

5. Delete the association of your SR and the PBD:

xe sr-forget uuid=your-SR-uuid

P.S. Thanks to Citrix Forum

Unexpected problems of exporting VM's in XenServer 6.1 as .OVA

Yesterday I experienced problems with exporting VM from XenServer. The problem appeared only when I chose Open Format exporting instead of XVA. When the task started, it tried to connect to some virtual disk and then failed. Close investigation of the log file revealed that the following error message was added:

transfer: ERROR    expose: XenAPI.Failure: ['XENAPI_PLUGIN_FAILURE', 'prepare_transfervm_template', 'Failure', "['NO_TEMPLATE', 'There has been an error installing the Transfer VM template']"]

After searching the web I found an advice to check whether XenServer Transfer VM is present in the list of VM. For it to be shown we have to enable displaying of hidden objects (View -> Hidden Objects). This VM was missing. Then I found a guide on how to reinstall it. On XenServer host:

cd /opt/xensource/packages/files/transfer-vm

./install-transfer-vm.sh

When I started the script it displayed an error stating that I do not have Local Storage as well as Default Storage. In fact I had Local Storage, but it wasn't set as default! When I checked it as my default storage, the script ran without a problem and exporting began to work as expected!

Hint: Looks like if you didn't create your Local SR on the initial installation and then did it manually, it wouldn't be set as Default, so the exporting wouldn't work!

Installing and fine-tuning XenServer 6.1 on server with Adaptec 6805 RAID controller

• For XenServer 6.1 to recognize logical array, first of all we have to download precompiled driver package (aacraid_linux_min_drivers.tgz) from adaptec site (link), then burn it to CD and press F9 when installation prompts to. 
• After installation completion, it's time to install Adaptec Storage Manager agent on XenServer and configure it to connect to central location with Windows-based GUI. Download it from here. Choose the latest version for 32-bit Linux (yes, 32-bit). It's a mystery for me why 64-bit Xen doesn't want to install 64-bit ASM, but it's true.

At my Linux shell: scp ~/Downloads/StorMan.rpm root@10.10.X.X:/tmp

At my XenServer shell: rpm --install ./StorMan.rpm

• At this point ASM agent should be installed on XenServer. Now we should open appropriate TCP and UDP ports in XenServer firewall to allow connections from ASM installed on central Windows management station. ASM requires the following ports to be opened for successful connection to be established (from the User Guide):

8003 (TCP)

34570 to 34580 (TCP)

34570 (UDP)

34577 to 34580 (UDP) 

•  After opening ports, we should be able to connect to Xen's ASM agent from management station by using login "root" and appropriate password.
• We can now configure any parameters of our RAID array remotely, but something still doesn't work. And it's alerting system. Agent can't send e-mail notification, SNMP traps, etc. To make this work, we should modify /etc/hosts file and add the following lines:

127.0.0.1 localhost.localhost     localhost

10.10.X.X   xenserver.YOURDOMAIN.COM xenserver

10.10.X.X     asm.YOURDOMAIN.COM          asm

• where "xenserver" is...yes, it's XenServer :D and asm.YOURDOMAIN.COM is IP address and FQDN of you management station. Actually, I guess that the last line is not necessary, but it's present in my configuration, so I don't want to alter working system.

Some remarks on HP ProCurve networking terminology

For me, HP networking is just a world of confusion.

Let's see how looks like assignment of a different ports to a VLAN:

vlan 100
   no untagged 10,19-20
   untagged 11-18,21-24
   tagged Trk1-Trk3
   ip address X.X.X.X 255.255.255.248

Previous commands have the following meaning:

no untagged 10,19-20 - these ports do NOT pass the traffic of this VLAN;

untagged 11-18,21-24 - these ports pass the traffic without 802.1q tags;

tagged Trk1-Trk3 - traffic is tagged with 802.1q headers.

"no untagged" command is just makes my head spinning. :)