Installing Loopback interface in Windows 7

This tutorial will show you how to install a Loopback interface in Windows which can later be used to make GNS3 connect to real physical devices or even the internet.

1. Open the start menu and type hdwwiz
2. A wizard to install hardware will appear, Click next

3. Click the dial to install hardware manually then next

4.Scroll down till Network adapters, highlight then click next

5. On the manufacturer side, make sure you highlight Microsoft, then choose Microsoft Loopback Adapter.

6. Click Next then Finish , Just make sure you restart your computer before using it.

LDP - IGP Synchronization

A common problem with MPLS L3-VPNs happens when the LSP between PE routers is broken which tends to drop traffic customers connected to those PEs. The reason is that VPN Labels (which is the lower label) are unknown to PE routers. This happens because IGPs like OSPF converges before LDP. So a path between PE is present but there's no labels exchanged yet, which makes P router pops the upper label and send the packet to it's neighbor P router which has no idea what to do with the lower label since it's not aware of VRF. which can cause black-hole in the network for sometime until LDP converges again.

A solution to this is using LDP-IGP synchronization. The idea is fairly simple, OSPF will not prefer the link to the neighbor router with the affected link until LDP has been fully converged over that link, to avoid packets with VPN labels from being forwarded to the unaware P routers. Of course this solution is used when you have redundant links or paths between P routers, other than that, OSPF will continue to forward the packets if its the only path.

Now let's see how this works in the topology below

From the topology above, R8,R9 and R12 are P Routers, while R6 and R13 are PE routers. Now, when R13 is trying to reach R6, OSPF will calculate the shortest path which is R13 - R12 - R6. 

let's see the configuration of the vrf on R13

R13#show run vrf a
Building configuration...
Current configuration : 793 bytes
ip vrf a
 rd 100:1
 route-target export 100:1
 route-target import 100:1
!
!
interface FastEthernet2/1
 ip vrf forwarding a
 ip address 10.1.13.13 255.255.255.0
 duplex auto
 speed auto
 !
!
interface Loopback10
 ip vrf forwarding a
 ip address 130.130.130.130 255.255.255.255
 !
!
router ospf 10 vrf a
 log-adjacency-changes
 redistribute bgp 1 subnets
 network 10.1.13.13 0.0.0.0 area 0
 network 130.130.130.130 0.0.0.0 area 0
!
!
router bgp 1
 !
 address-family ipv4 vrf a
  no synchronization
  network 130.130.130.130 mask 255.255.255.255
  redistribute connected
 exit-address-family
!
end

Now let's trace the path to R6 loopback in VRF a

R13#traceroute vrf a 66.66.66.66 source lo10
Type escape sequence to abort.
Tracing the route to 66.66.66.66
  1 10.12.13.12 [MPLS: Labels 22/30 Exp 0] 28 msec 48 msec 48 msec
  2 66.66.66.66 72 msec *  76 msec

Let's see what labels R13 are imposing on the packet going to R6

R13#show mpls forwarding-table vrf a 66.66.66.66 detail
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
None       30         66.66.66.66/32[V]   \
                                       0             Fa2/0      10.12.13.12
        MAC/Encaps=14/22, MRU=1496, Label Stack{22 30}
        CA0A585C0038CA073EC400388847 000160000001E000
        VPN route: a
        No output feature configured
 

We can see the label 22 which is used to forward the packet to R12 and label 30 which is used to identify the VPN.

The catch here is that MP-BGP exchanges updates through the loopback in the global routing table. looking at the forwarding table of R12 now to R6 global loopback IP address

R12#show mpls forwarding-table 6.6.6.6
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
22         Pop Label  6.6.6.6/32       23060         Fa2/1      10.6.12.6

We can see here that R12 is doing a PHP penultimate hop popping before forwarding the packet to R6. which leaves only label 30 that will be later used by R6 to identify which VPN.

Now lets simulate LDP faliure between R12 and R6, while keeping the OSPF neighborship up

R6(config)#int f2/1R6(config-if)#no mpls ip
R6(config-if)#
*Jun 24 00:31:00.663: %LDP-5-NBRCHG: LDP Neighbor 12.12.12.12:0 (3) is DOWN (LDP disabled on interface)

R12#show mpls forwarding-table 6.6.6.6
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
22         No Label   6.6.6.6/32       9598          Fa2/1      10.6.12.6

We can see now that R12 still prefers F2/1 as the outgoing interface since OSPF is used for the metric calculation, not LDP. Since there's no LDP neighborship on interface F2/1, R12 will send the packet with no label, and will try to recursevily look for ip 66.66.66.66 which will not be found in it's routing table since it's not VRF aware in the first place. 

To confirm that, the ping from R13 to R6 should fail

R13#ping vrf a 66.66.66.66 source lo10 repe 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 66.66.66.66, timeout is 2 seconds:
Packet sent with a source address of 130.130.130.130
..........

After this long introduction to the problem, let's see how we can solve this issue using the LDP-IGP sync.

As mentioned before, LDP-IGP sync makes sure that traffic will now flow through the link that has no LDP neighborship but has an OSPF neighborship by 2 means. Either by sending the OSPF maximum metric to the downstream neighbor or by preventing the OSPF neighborship from coming up until LDP has converged.

let's see how this works by configuring LDP-IGP sync on R12

R12#show run | s router ospf 1
router ospf 1
 mpls ldp sync
 log-adjacency-changes

R12(config)#int f2/1
R12(config-if)#mpls ldp igp sync

now let's see how R12 interface F2/1 metric is maxed to 65535

R12#show ip ospf mpls ldp inter f2/1
FastEthernet2/1
  Process ID 1, Area 0
  LDP is not configured through LDP autoconfig
  LDP-IGP Synchronization : Required
  Holddown timer is not configured
  Interface is up and sending maximum metric

now let's check what is the maximum metric from R12 side. 

R12#show ip ospf database router 6.6.6.6
            OSPF Router with ID (12.12.12.12) (Process ID 1)
                Router Link States (Area 0)
  LS age: 571
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 6.6.6.6
  Advertising Router: 6.6.6.6
  LS Seq Number: 8000000C
  Checksum: 0x2E09
  Length: 60
  Number of Links: 3
    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 6.6.6.6
     (Link Data) Network Mask: 255.255.255.255
      Number of MTID metrics: 0
       TOS 0 Metrics: 1
    Link connected to: a Transit Network
     (Link ID) Designated Router address: 10.6.8.8
     (Link Data) Router Interface address: 10.6.8.6
      Number of MTID metrics: 0
       TOS 0 Metrics: 1
    Link connected to: a Transit Network
     (Link ID) Designated Router address: 10.6.12.12
     (Link Data) Router Interface address: 10.6.12.6
      Number of MTID metrics: 0
       TOS 0 Metrics: 65535

R12 is now considering the link between itself and R6 unusable to forward packet since it's OSPF metric is the maximum metric. based on that, OSPF fall back to another path to reach R6. 

Let's trace route again from R13 to see if it works this time.

R13#traceroute 6.6.6.6 probe 1
Type escape sequence to abort.
Tracing the route to 6.6.6.6
  1 10.12.13.12 [MPLS: Label 22 Exp 0] 24 msec
  2 10.8.9.8 [MPLS: Label 25 Exp 0] 56 msec
  3 10.6.8.6 120 msec

The traffic path now is R13-R12-R8-R6, since LDP is running between all the involved links VPN traffic should pass normally as before but in the new path

R13#ping vrf a 66.66.66.66 source lo10 repe 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 66.66.66.66, timeout is 2 seconds:
Packet sent with a source address of 130.130.130.130
!!!!!!!!!!
Success rate is 100 percent (10/10), round-trip min/avg/max = 12/40/68 ms

Seems that everything is fine now. But what about simulating that R12 has just been rebooted, or the link between R12 and R6 was completely down and just came up. actually synchronization will behave a little differently but will give the same effect as illustrated before.

R12#show ip ospf mpls ldp interface f2/1
FastEthernet2/1
  Process ID 1, Area 0
  LDP is not configured through LDP autoconfig
  LDP-IGP Synchronization : Required
  Holddown timer is not configured
  Interface is down and pending LDP

In the case of a reload or a link failure until the OSPF timers expire then coming up again. The Synchronization will prevent the OSPF neighborship between R12 and R6 from forming on interface FastEthernet2/1, Thus R13 will have to find another route to R6

R12#  show ip ospf interface  brief
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Lo0          1     0               12.12.12.12/32     1     LOOP  0/0
Fa2/1        1     0               10.6.12.12/24      1     DOWN  0/0
Fa2/0        1     0               10.12.13.12/24     1     BDR   1/1
Fa1/1        1     0               10.9.12.12/24      1     DR    1/1
Fa1/0        1     0               10.8.12.12/24      1     DR    1/1

Finally, how long should this state of unusable link continue like this? well, unless you configure a hold down timer to the LDP-IGP synchronization, the unusable state of the link will be permanent until LDP session is restored or the manually configured hold down timer expires.

The hold down timer can be configured from the global configuration mode.

R12(config)#mpls ldp igp sync holddown ?
  <1-2147483647>  Hold down time in milliseconds
R12(config)#mpls ldp igp sync holddown 10000

The LDP-IGP can be very useful during the period After the IGP has converged but Before LDP convergence to avoid L3-VPN traffic from dropping. 

BGP redistribution to OSPF automatic route Tagging

When redistributing from plain BGP to OSPF, Cisco IOS tends to Tag that external route with the AS of the Best Route in BGP table. This mechanism is heavily in MPLS PE-CE networks as a loop prevention mechanism, though this post is about plain IP network which is just analysis of how it's done

Here's the Lab topology I decided to test out that feature:

Now let's see the subnet between R4 and R11 in the  BGP table of R2

R2#show ip bgp 10.4.11.0
BGP routing table entry for 10.4.11.0/24, version 4
Paths: (2 available, best #2, table default)
  Advertised to update-groups:
     1
  300
    10.2.11.11 from 10.2.11.11 (11.11.11.11)
      Origin incomplete, metric 0, localpref 100, valid, external
  200
    10.2.4.4 from 10.2.4.4 (4.4.4.4)
      Origin incomplete, metric 0, localpref 100, valid, external, best

It seems that R2 prefers the prefix coming from R4 in AS 200 because of the lowest originator-id. 

Now let's redistribute BGP into OSPF on R2

router ospf 1
 log-adjacency-changes
 redistribute bgp 100 subnets

R2 is now considered an ASBR to OSPF process 1, now we should see the prefix 10.4.11.0/24 tagged with AS-200 automatically

R2#show ip ospf database external 10.4.11.0
            OSPF Router with ID (2.2.2.2) (Process ID 1)
                Type-5 AS External Link States
  LS age: 47
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 10.4.11.0 (External Network Number )
  Advertising Router: 2.2.2.2
  LS Seq Number: 80000002
  Checksum: 0xDCEB
  Length: 36
  Network Mask: /24
        Metric Type: 2 (Larger than any link state path)
        MTID: 0
        Metric: 1
        Forward Address: 0.0.0.0
        External Route Tag: 200

Now let's simulate that the neighborship between R2 and R4 is down, R2 should see one route to 10.4.11.0/24 through R11 and select that as the best, eventually the route should be tagged to the AS of R11 which is 300

 R2#show run | s router bgp
router bgp 100
 no synchronization
 bgp log-neighbor-changes
 neighbor 10.2.4.4 remote-as 200
 neighbor 10.2.4.4 shutdown
 neighbor 10.2.11.11 remote-as 300

R2#show ip bgp 10.4.11.0
BGP routing table entry for 10.4.11.0/24, version 18
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  300
    10.2.11.11 from 10.2.11.11 (11.11.11.11)
      Origin incomplete, metric 0, localpref 100, valid, external, best

Now that R2 can only one path to 10.4.11.0/24 through R11, let's see how that prefix looks like in the OSPF database

R2#show ip ospf database external 10.4.11.0

            OSPF Router with ID (2.2.2.2) (Process ID 1)

                Type-5 AS External Link States

  LS age: 168

  Options: (No TOS-capability, DC)

  LS Type: AS External Link

  Link State ID: 10.4.11.0 (External Network Number )

  Advertising Router: 2.2.2.2

  LS Seq Number: 80000003

  Checksum: 0xE87A

  Length: 36

  Network Mask: /24

        Metric Type: 2 (Larger than any link state path)

        MTID: 0

        Metric: 1

        Forward Address: 0.0.0.0

        External Route Tag: 300

This technique is used in what is called a Domain-Tag. As previously mention at the beginning of the post, to prevent loops between PE and CE routers.

I'll write a more detailed post on OSPF as a PE CE protocol and how the route tagging is used.

QoS Groups

QoS Groups are locally significant groups that can categorize different classes of traffic together under one group, you can configure 1024 qos groups (0-1023). Since it is only locally significant to the router, it can only be set in the Ingress direction and matched in the Egress direction.

The advantage of the qos-groups command is that it can group different class-maps that has different matches in the ingress direction and give them the same treatment while exiting the router from another interface.

Let's see how it works on this simple topology:

R2 --- R3 --- R1

Now R3 has two class-maps that matches Telnet and ICMP traffic coming from R2 heading to R1 and a policy map that attaches these two class-maps to a single qos-group

Ingress Direction from R2
R3#
class-map match-all telnet
 match protocol telnet
class-map match-all icmp
 match protocol icmp

policy-map input
 class telnet
  set qos-group 1
 class icmp
  set qos-group 1

interface FastEthernet1/0
 ip address 10.2.3.3 255.255.255.0
 ip ospf 1 area 0
 duplex auto
 speed auto
 !
 service-policy input input

Now let's check the Egress policy to R1

Egress Direction to R3
R3#
class-map match-all output
 match qos-group 1

policy-map output
 class output
  set precedence 5

interface FastEthernet1/1
 ip address 10.1.3.3 255.255.255.0
 ip ospf 1 area 0
 duplex auto
 speed auto
 !
 service-policy output output
end

As shown in the example above, both class-maps will be treated the same as they will be marked with precedence 5 while exiting the interface towards R1.

Of course the class-map can be more complicated than that.. it may include all the conventional matches of MQC but this is only for illustration.

Resolving OSPF neighbor router-id to hostname

In Large networks, you may find it hard to remember which OSPF neighbor is on a certain link. Of course if you can memorize the router-id of each router in your network that would be amazing, but for someone like me it can be a pain while working on something that needs to be done fast since i have to jot down the topology with IPs on just to remember who's who in the network.

Luckily, there's a command in Cisco IOS that can resolve OSPF neighbor router-id into it's hostname.

ip ospf name-lookup

This is a Global configuration command, now let's see how a typical OSPF show neighbor command looks like

R1#show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface

2.2.2.2           1   FULL/DR         00:00:31    10.1.2.2        FastEthernet1/0

As you can see, R1 see neighbor R2 by it's router-id, now let's make it see it by hostname

First we need to map R2 hostname to the IP on R1 then configure OSPF router-id hostname resolving.


R1(config)#ip host R2 2.2.2.2

R1#show hosts
Default domain is not set
Name/address lookup uses domain service using source interface Loopback0
Name servers are 2.2.2.2
Codes: UN - unknown, EX - expired, OK - OK, ?? - revalidate
       temp - temporary, perm - permanent
       NA - Not Applicable None - Not defined
Host                      Port  Flags      Age Type   Address(es)
R2                        None  (perm, OK)  0   IP    2.2.2.2

As shown above, the hostname R2 can now be resolved to 2.2.2.2 locally on R1, now let's make OSPF resolve hostnames from router-ids

R1(config)#ip ospf name-lookup

R1#show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface

R2                1   FULL/DR         00:00:33    10.1.2.2        FastEthernet1/0

As you can see now, the show command displays the hostname instead of the router-id, which be very useful. one thing to notice though is that if you're using an external DNS server for name resolution, it can get very slow when using the show commands because of the name lookup process.

Cisco Routing Protocols Redistribution Initial Metrics

One Interesting topic is redistribution between various routing protocols. Every routing protocol has a way to calculate the best path to the end destination, RIP for example uses number of hops whether the links between the routers is slow or fast. EIGRP uses it's complicated metric utilizing reliability, MTU, delay etc.. to calculate the best path to the destination. to put that into prospective, if we have the same topology and we decided to run OSPF instead of RIP, most certainly the traffic path will be changed due to the way the metric sees the best path.

Our topic here is what metric will a route have if it's redistributed from one protocol to another? 

The table below shows the default initial metrics that are assigned by protocols incase of redistribution between different protocols.

There are some facts when it comes to redistribution, like:

1. Redistribution between similar protocols will not do any change to the metric.
2. EIGRP and RIP will not redistribute other protocols unless the initial metric is set manually.
3. Connected and Static Routes will always have initial metrics to any protocols since their distribution is only one way redistribution and the fact that they're always local to the router.
4. BGP Multi-Exit Discriminator ( MED ) will be used as metric in case of redistribution.

BGP Atomic Aggregate

When a router performs aggregation in BGP, there are some options that can allow the aggregate and the aggregated routes to be passed on to the next neighbor or autonomous system.

The Atomic Aggregate is simply a Well-Known Optional attribute that specifies that this is an aggregated route that might or might-not be originated from the advertising AS, that is because the aggregated route is a generated route, it technically doesn't exist, but it represents a contiguous group of addresses in just one.

In the topology shown above, R6 in AS 500 is originating the prefixes 192.168.1.0/24 through 192.168.6.0/24. these prefixes are then propagated to AS 600 then to AS 100. Let's see how they look on R1 in AS 100.

R1#show ip bgp | i 192

*> 192.168.1.0      8.8.8.8                                0 600 500 ?

*> 192.168.2.0      8.8.8.8                                0 600 500 ?

*> 192.168.3.0      8.8.8.8                                0 600 500 ?

*> 192.168.4.0      8.8.8.8                                0 600 500 ?

*> 192.168.5.0      8.8.8.8                                0 600 500 ?

*> 192.168.6.0      8.8.8.8                                0 600 500 ?

As the output shows above, the Originating AS is AS 500, then it traversed AS 600 to reach R1. Now let's perform Aggregation on R8 without suppressing the original /24 routes.

R8(config-router)#aggregate-address 192.168.0.0 255.255.0.0

R1#show ip bgp | i 192

*> 192.168.0.0/16   8.8.8.8                  0             0 600 i

*> 192.168.1.0      8.8.8.8                                0 600 500 ?

*> 192.168.2.0      8.8.8.8                                0 600 500 ?

*> 192.168.3.0      8.8.8.8                                0 600 500 ?

*> 192.168.4.0      8.8.8.8                                0 600 500 ?

*> 192.168.5.0      8.8.8.8                                0 600 500 ?

*> 192.168.6.0      8.8.8.8                                0 600 500 ?

  

BGP routing table entry for 192.168.0.0/16, version 21

Paths: (1 available, best #1, table default)

  Not advertised to any peer

  600, (aggregated by 600 8.8.8.8)

    8.8.8.8 from 8.8.8.8 (8.8.8.8)

      Origin IGP, metric 0, localpref 100, valid, external, atomic-aggregate, best

As shown in the above output, the aggregated route from R1 prospective is originated from AS 600 , and it is indicated that update that this is an aggregated route. R1 can't confirm if this route was originated in AS 600 or not. Now let's suppress the other routes to show how this can be confusing if you're trying to know the source of these prefixes by adding the summary-only  to the aggregation command on R8

R8(config-router)#aggregate-address 192.168.0.0 255.255.0.0 summary-only

R1#show ip bgp | i 192

*> 192.168.0.0/16   8.8.8.8                  0             0 600 i

as you can see, R1 can only see the aggregated route and it's origin is AS 600 which can be very misleading. Let's see a capture of the BGP update packet to go in deep into it

Well, the capture here explains it in depth to make it really easy to understand what's going on. There are 2 BGP updates, the first one is for the aggregated route which described the prefix and the originating AS which is 600. while the other BGP updates tells router R1 to withdraw the more specific prefixes which show's how the summary-only works

Of course BGP is a policy protocol which is capable of almost anything when it comes to prefix manipulation, and also to preserve the integrity of the routes between different ASs since service providers might only accept certain prefixes which is originating from their real originating AS as a part of prefix origin validation. There's another option that keeps the originating AS in the atomic aggregate update which is as-set. Now let's add the as-set option to the aggregate command and see how would that affect the aggregated prefix origin.

R8(config-router)#aggregate-address 192.168.0.0 255.255.0.0 summary-only as-set

R1#show ip bgp | i 192

*> 192.168.0.0/16   8.8.8.8                  0             0 600 500 ?

R1#show ip bgp 192.168.0.0

BGP routing table entry for 192.168.0.0/16, version 28

Paths: (1 available, best #1, table default)

  Not advertised to any peer

  600 500, (aggregated by 600 8.8.8.8)

    8.8.8.8 from 8.8.8.8 (8.8.8.8)

      Origin incomplete, metric 0, localpref 100, valid, external, best

Now it looks like R1 is getting the origin of 192.168.0.0/16 as AS 500. Unfortunately, R1 can never be sure if the smaller prefixes was originated by AS 500 because AS 500 might have aggregated the /24 subnets from another AS into /18 for example and then R8 aggregated those /18 into a /16. All R1 knows that smaller prefixes from AS 500 was aggregated at R8 in AS 600.

BGP disable-connected-check and ebgp-multihop

For eBGP neighborship to form between two routers, by default; the routers send a TCP ACK with a TTL of 1. then an Open message is sent to negotiate some parameters that BGP neighbors must know about each other like version number and capabilities etc.

For directly connected neighbors, it's pretty straight forward. But when using the loopback for form the the neighborship, there's an extra hop for that TCP session to be established.

Lets consider the following topology here

Forming neighborship through directly connected interfaces between R1 and R2 wouldn't be a problem with default configuration, all you need is TCP packets with TTL of 1. We can check that using the following command

R1#show ip bgp neighbors

BGP neighbor is 10.1.2.2,  remote AS 2, external link

  BGP version 4, remote router ID 2.2.2.2
  BGP state = Established, up for 00:06:07
  Last read 00:00:47, last write 00:00:49, hold time is 180, keepalive interval is 60 seconds
  Neighbor sessions:
    1 active, is multisession capable
  Neighbor capabilities:
    Route refresh: advertised and received(new)
    Four-octets ASN Capability: advertised and received
    Address family IPv4 Unicast: advertised and received
    Multisession Capability: advertised and received
  Message statistics, state Established:
    InQ depth is 0
    OutQ depth is 0

                         Sent       Rcvd
    Opens:                  1          1
    Notifications:          0          0
    Updates:                1          1
    Keepalives:             8          8
    Route Refresh:          0          0
    Total:                 10         10
  Default minimum time between advertisement runs is 30 seconds

  Address tracking is enabled, the RIB does have a route to 10.1.2.2
  Connections established 1; dropped 0
  Last reset never
  Transport(tcp) path-mtu-discovery is enabled
  Graceful-Restart is disabled
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 1
Local host: 10.1.2.1, Local port: 29870
Foreign host: 10.1.2.2, Foreign port: 179
Connection tableid (VRF): 0
Maximum output segment queue size: 50

Enqueued packets for retransmit: 0, input: 0  mis-ordered: 0 (0 bytes)

Event Timers (current time is 0x296C9C):
Timer          Starts    Wakeups            Next
Retrans             9          0             0x0
TimeWait            0          0             0x0
AckHold             9          8             0x0
SendWnd             0          0             0x0
KeepAlive           0          0             0x0
GiveUp              0          0             0x0
PmtuAger            1          0        0x2CD508
DeadWait            0          0             0x0
Linger              0          0             0x0
ProcessQ            0          0             0x0

iss: 3161157976  snduna: 3161158210  sndnxt: 3161158210     sndwnd:  16151
irs: 1964609928  rcvnxt: 1964610181  rcvwnd:      16132  delrcvwnd:    252

SRTT: 210 ms, RTTO: 904 ms, RTV: 694 ms, KRTT: 0 ms
minRTT: 64 ms, maxRTT: 300 ms, ACK hold: 200 ms
Status Flags: active open
Option Flags: nagle, path mtu capable
IP Precedence value : 6

Datagrams (max data segment is 1460 bytes):
Rcvd: 18 (out of order: 0), with data: 11, total data bytes: 252
Sent: 21 (retransmit: 0, fastretransmit: 0, partialack: 0, Second Congestion: 0), with data: 11, total data bytes: 252
 Packets received in fast path: 0, fast processed: 0, slow path: 0
 fast lock acquisition failures: 0, slow path: 0

Now, we can form this neighborship over loopbacks. we'll just change the configuration a little bit and see what will happen.

Configuration has been changed so that both routers use their loopback to establish the BGP peering

router bgp 1
 no synchronization
 bgp log-neighbor-changes
 neighbor 2.2.2.2 remote-as 2
 neighbor 2.2.2.2 update-source Loopback0
 no auto-summary

R1#show ip bgp neighbors 2.2.2.2
BGP neighbor is 2.2.2.2,  remote AS 2, external link
  BGP version 4, remote router ID 0.0.0.0
  BGP state = Idle
  Neighbor sessions:
    0 active, is multisession capable
  Default minimum time between advertisement runs is 30 seconds
 For address family: IPv4 Unicast
  BGP table version 1, neighbor version 1/0
  Output queue size : 0
  Index 0
                                 Sent       Rcvd
  Prefix activity:               ----       ----
    Prefixes Current:               0          0
    Prefixes Total:                 0          0
    Implicit Withdraw:              0          0
    Explicit Withdraw:              0          0
    Used as bestpath:             n/a          0
    Used as multipath:            n/a          0
                                   Outbound    Inbound
  Local Policy Denied Prefixes:    --------    -------
    Total:                                0          0
  Number of NLRIs in the update sent: max 0, min 0
  Address tracking is enabled, the RIB does not have a route to 2.2.2.2
  Connections established 0; dropped 0
  Last reset never
  External BGP neighbor not directly connected.
  Transport(tcp) path-mtu-discovery is enabled
  Graceful-Restart is disabled
  No active TCP connection
 

 Now there's no active TCP connection between the two routers, and the router knows that this IP isn't on any of it's connected interfaces, so it must be "not directly connected". let's make it reachable for both routers by configuring static routes to each other loopbacks.

Note: I'll remove some of the unneeded outputs to make the output more to the point of discussion

R1(config)#ip route 2.2.2.2 255.255.255.255 10.1.2.2

R1#show ip bgp neighbors
BGP neighbor is 2.2.2.2,  remote AS 2, external link
  BGP version 4, remote router ID 0.0.0.0
  BGP state = Idle
  Neighbor sessions:
    0 active, is multisession capable
  Default minimum time between advertisement runs is 30 seconds
 For address family: IPv4 Unicast
  BGP table version 1, neighbor version 1/0
  Output queue size : 0
  Index 0

  Number of NLRIs in the update sent: max 0, min 0
  Address tracking is enabled, the RIB does have a route to 2.2.2.2
  Connections established 0; dropped 0
  Last reset never
  External BGP neighbor not directly connected.
  Transport(tcp) path-mtu-discovery is enabled
  Graceful-Restart is disabled
  No active TCP connection

Now the router seems to have a route to it's neighbor, but the TCP connection won't come up. well the reason is, as we mentioned before , the default behavior for EBGP neighborship is to send packets with TTL of 1.  

For that to work, there are two solutions that might look very similar, but actually they are intended for different purposes, disable-connected-check and ebgp-multihop commands.

 disable-connected-check still sends packets with TTL of 1, but the directly connected router must have the peering address configured on it. while ebgp-multihop can allow the packet to traverse through it to a router behind it (up to 255 hops). 

here's what it looks like on R1

R1#sho ip bgp neighbors
BGP neighbor is 2.2.2.2,  remote AS 2, external link
  BGP version 4, remote router ID 2.2.2.2
  BGP state = Established, up for 00:17:07
  Last read 00:00:12, last write 00:00:17, hold time is 180, keepalive interval is 60 seconds
  Neighbor sessions:
    1 active, is multisession capable
  Address tracking is enabled, the RIB does have a route to 2.2.2.2
  Connections established 2; dropped 1
  Last reset 00:17:29, due to User reset of session 1
  External BGP neighbor not directly connected.
  Transport(tcp) path-mtu-discovery is enabled
  Graceful-Restart is disabled
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 1

as you can see, the router sends packets with TTL of 1, now let's see how ebgp-multihop will work

router bgp 1
 no synchronization
 bgp log-neighbor-changes
 neighbor 2.2.2.2 remote-as 2
 neighbor 2.2.2.2 ebgp-multihop 2
 neighbor 2.2.2.2 update-source Loopback0
 no auto-summary

R1#show ip bgp neighbors
BGP neighbor is 2.2.2.2,  remote AS 2, external link
  BGP version 4, remote router ID 2.2.2.2
  BGP state = Established, up for 00:37:21
  Last read 00:00:20, last write 00:00:38, hold time is 180, keepalive interval is 60 seconds  Address tracking is enabled, the RIB does have a route to 2.2.2.2
  Connections established 2; dropped 1
  Last reset 00:37:43, due to User reset of session 1
  External BGP neighbor may be up to 2 hops away.
  Transport(tcp) path-mtu-discovery is enabled
  Graceful-Restart is disabled
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 2
Local host: 1.1.1.1, Local port: 39820
Foreign host: 2.2.2.2, Foreign port: 179

OSPF Forwarding Address

OSPF forwarding address was introduced to overcome sub-optimal routing that can happen in certain scenarios when the ASBR redistributes external routes and flood it into an area. One of these cases can be illustrated in the following topology

Let us assume the following scenario where R2 and ASBR are connected to both the RIP domain and OSPF domain, but only ASBR is doing mutual redistribution between OSPF and RIP. the ASBR will start flooding external routes inside Area 0 announcing itself as the forwarding address to reach these external networks.

ASBRs announces the forwarding address in two modes:

Zero forwarding address 0.0.0.0 and Non-Zero forwarding address

Zero Forwarding address tells the rest of the routers in the OSPF domain that the ASBR itself is your gateway to get to the external routes, in our case here R2 and R4 can R1 loopback0 1.1.1.1 route as follow:

R2#show ip route 1.1.1.1
Routing entry for 1.1.1.1/32
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 10
  Last update from 10.2.3.3 on FastEthernet0/1, 01:01:13 ago
  Routing Descriptor Blocks:
  * 10.2.3.3, from 3.3.3.3, 01:01:13 ago, via FastEthernet0/1
      Route metric is 20, traffic share count is 1

  R2#show ip ospf database external 1.1.1.1            OSPF Router with ID (2.2.2.2) (Process ID 1)                Type-5 AS External Link States

  Routing Bit Set on this LSA

  LS age: 1789

  Options: (No TOS-capability, DC)

  LS Type: AS External Link

  Link State ID: 1.1.1.1 (External Network Number )

  Advertising Router: 3.3.3.3

  LS Seq Number: 80000002

  Checksum: 0x5D32

  Length: 36

  Network Mask: /32

        Metric Type: 2 (Larger than any link state path)

        TOS: 0

        Metric: 20

        Forward Address: 0.0.0.0

        External Route Tag: 0

R4# show ip route 1.1.1.1
Routing entry for 1.1.1.1/32
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 11
  Last update from 10.2.4.2 on FastEthernet0/0, 01:03:44 ago
  Routing Descriptor Blocks:
  * 10.2.4.2, from 3.3.3.3, 01:03:44 ago, via FastEthernet0/0
      Route metric is 20, traffic share count is 1

R4#show ip ospf database external 1.1.1.1
            OSPF Router with ID (4.4.4.4) (Process ID 1)
                Type-5 AS External Link States
  Routing Bit Set on this LSA
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 1.1.1.1 (External Network Number )
  Advertising Router: 3.3.3.3
  LS Seq Number: 80000002
  Checksum: 0x5D32
  Length: 36
  Network Mask: /32
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 20
        Forward Address: 0.0.0.0
        External Route Tag: 0

  LS age: 1910

Looking at the above outputs, it's easily seen that any traffic sourcing from R4 heading to R1 will take the path R4 - R2 - ASBR - R1, which is considered sub-optimal routing since it takes an extra hop compared to the path R4 - R2 - R1. Even for R2 the way to get to R1 is through the ASBR.

A traceroute to verify the traffic path.

R2#traceroute 1.1.1.1
Type escape sequence to abort.
Tracing the route to 1.1.1.1
  1 10.2.3.3 28 msec 28 msec 4 msec
  2 20.1.123.1 36 msec 36 msec 16 msec

R4#traceroute 1.1.1.1
Type escape sequence to abort.
Tracing the route to 1.1.1.1
  1 10.2.4.2 20 msec 32 msec 12 msec
  2 10.2.3.3 28 msec 20 msec 16 msec
  3 20.1.123.1 56 msec 40 msec 24 msec

Now to overcome this behavior OSPF forwarding address can be set no a Non-Zero by meeting some of these conditions:

• OSPF is enabled on the ASBR's next hop interface AND
• ASBR's next hop interface is non-passive under OSPF AND
• ASBR's next hop interface is not point-to-point AND
• ASBR's next hop interface is not point-to-multipoint AND
• ASBR's next hop interface address falls under the network range specified in the router ospf command.
• Any other conditions besides these set the forwarding address to 0.0.0.0

Now let's enable OSPF on int F0/0 attached to ASBR, and since it's an Ethernet; it defaults to be a network type Broadcast OSPF interface and since it's the same subnet with router R2 in the RIP domain, we've got all the above conditions covered.

ASBR(config)#int f0/0
ASBR(config-if)#ip ospf 1 a 0

Of course there will be NO neighborship formed on this interface with any of the other routers on the same segment, but the idea is OSPF external routes can't use external routes as next-hops, so the ASBR presents it self as the forwarding address to that external route, and by advertising network 20.1.123.0/24 into the OSPF area as type-1 LSA, that overcomes that problem.

When the packet sourced from R4 reaches R2 on it's way to R1 loopback, the forwarding address is then directly connected to R2, that's when R2 decided it should route the packet through it's F0/0 interface eliminating that extra hop through the ASBR, which tells why the ASBR and R2 interfaces should be an OSPF broadcast type and in the same subnet.

let's see what R2 and R4 routing table and OSPF database now

R2#show ip route 1.1.1.1
Routing entry for 1.1.1.1/32
  Known via "rip", distance 120, metric 1
  Redistributing via rip
  Last update from 20.1.123.1 on FastEthernet0/0, 00:00:06 ago
  Routing Descriptor Blocks:
  * 20.1.123.1, from 20.1.123.1, 00:00:06 ago, via FastEthernet0/0
      Route metric is 1, traffic share count is 1

R2#show ip ospf database external 1.1.1.1

            OSPF Router with ID (2.2.2.2) (Process ID 1)
                Type-5 AS External Link States
  LS age: 882
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 1.1.1.1 (External Network Number )
  Advertising Router: 3.3.3.3
  LS Seq Number: 80000005
  Checksum: 0x9367
  Length: 36
  Network Mask: /32
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 20
        Forward Address: 20.1.123.1
        External Route Tag: 0

R4#show ip route 1.1.1.1
Routing entry for 1.1.1.1/32
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 21
  Last update from 10.2.4.2 on FastEthernet0/0, 02:07:15 ago
  Routing Descriptor Blocks:
  * 10.2.4.2, from 3.3.3.3, 02:07:15 ago, via FastEthernet0/0
      Route metric is 20, traffic share count is 1

R4#show ip ospf database external 1.1.1.1
            OSPF Router with ID (4.4.4.4) (Process ID 1)
                Type-5 AS External Link States
  Routing Bit Set on this LSA
  LS age: 1007
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 1.1.1.1 (External Network Number )
  Advertising Router: 3.3.3.3
  LS Seq Number: 80000005
  Checksum: 0x9367
  Length: 36
  Network Mask: /32
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 20
        Forward Address: 20.1.123.1
        External Route Tag: 0

Now you notice that for R2 and R4, the forwarding address is 20.1.123.1 which is the interface F0/0 connected to R1. Now for R2 to reach 1.1.1.1 it needs to forward the traffic to 20.1.123.1 which is directly connected to it's interface, so no need to send the traffic to the ASBR anymore since it will prefer the directly connected interface.

Now for R4, the advertising router is still 3.3.3.3 which is R3, but the forwarding address is changed to 20.1.123.1, and since packet destined from R4 to R1 must path through R2, R2 will forward the traffic with the same manner mentioned before also eliminating the need to go through that extra hop via the ASBR.

let's do a traceroute to finally see it in action

R2#traceroute 1.1.1.1
Type escape sequence to abort.
Tracing the route to 1.1.1.1
  1 20.1.123.1 32 msec 40 msec 28 msec


R4#traceroute 1.1.1.1
Type escape sequence to abort.
Tracing the route to 1.1.1.1
  1 10.2.4.2 32 msec 36 msec 12 msec
  2 20.1.123.1 28 msec 16 msec 40 msec

OSPF address forwarding can be very useful in  similar cases since it lessens the the traffic forwarding that the ASBR has to do between different routing domains, which makes the traffic flows through the optimal path ( which is totally relative to your design) and avoids congesting your ASBR inter-domain links.

Conncting GNS3 to the Internet

This two parts video will tell you how to easily connect your GNS3 routers and switches to the internet or real networking equipment, there's no limitations to what you can do after that, your imagination will be your limitation ;)

Just make sure you install a Loopback interface first in windows before you watch the video

Connecting GNS3 to the Internet Part 1

Connecting GNS3 to the Internet Part 2

Configuration annotation in Junos

When a box is managed by multiple people, sometimes this leads to confusion for people working on the box. The confusion can be illustrated as "what is this static route configured for?". A simple method can be by putting annotations or notes to the configuration to help the administrator know why this configuration or this IP was configured .

You can add an annotation using the annotate command, one thing to put in mind while putting it is that you have to be in edit mode the the hierarchy right above the thing you need to annotate.

here's an example of annotating a static route the points to a DNS server. let's first see how the configuration under the routing-options hierarchy looks like before annotating the static route

routing-options {
    static {
        route 4.2.2.2/32 next-hop 10.1.2.2;
        route 1.1.1.0/24 next-hop 20.1.1.2;
    }
}

now let's annotate that the IP 4.2.2.2 belongs to a DNS server

[edit]
root# edit routing-options static
[edit routing-options static]
root# annotate route 4.2.2.2/32 "DNS Server"

now let's see how the configuration looks like when showing the configuration looks like right now.

routing-options {
    static {
        /* DNS Server */
        route 4.2.2.2/32 next-hop 10.1.2.2;
        route 1.1.1.0/24 next-hop 20.1.1.2;
    }
}

As you can see, /*DNS Server*/ has been appended to the configuration to point out that the line right under it is a static route to 4.2.2.2.

one thing to notice here is that annotations can't be seen when showing the configuration with display set option.

root# show routing-options | display set
set routing-options static route 4.2.2.2/32 next-hop 10.1.2.2
set routing-options static route 1.1.1.0/24 next-hop 20.1.1.2

Using annotations can be very useful for multiple administrators working on the same box, annotations "almost" can be used anywhere inside the configuration.

Cisco IOS Configuration Archiving

Juniper has always been easier when rolling back configuration in case you messed up or you just wanted to try something and revert back to your good old working configuration, you can literally rollback to your old configuration with one command rollback 1  and you're back to the previous configuration. Cisco has a similar thing, although tedious; but it nearly gets the job done. The archive  command. There's a similar way to do this using the configure replace command.

You can get under the archive configuration hierarchy with the command arhcive in the global configuration mode

R2(config)#archive
R2(config-archive)#

now let's get to the good stuff. there are several features you can configure to achieve fully automated configuration archive.

First step is to configure the path in which you want the archived configurations to be saved at. personally, i prefer to make a directory to contain only the archived configurations. here's how to do it

R2#mkdir disk0:/archives
Create directory filename [archives]?
Created dir disk0:/archives

After making the directory, you need to point out  from the archive hierarchy to the directory we just created.

R2(config-archive)#path disk0:/archives/backup

Notice that after pointing to the archives directory, i added " /backup ", the reason is that you need to define a base name for the configurations to use is so that the backups name would be like backup-1 , backup-2 etc.. as it will increment till it reaches the highest configurable number which is 14, which can be configured with the maximum command

R2(config-archive)#maximum ?
  <1-14>  maximum number of backup copies
R2(config-archive)#maximum 14

now to make an snapshot of the configuration automatically each time you write your configuration to the memory you'll have enter this command 

R2(config-archive)#write-memory

Basically what it does is that it archives the configuration each time you issue the write command on your router which is good but, keep in mind that if you keep saving every time you enter some command things can get a little bit messy since it will keep archiving and incrementing . There's a way around this but it contradicts a little bit with the whole theory of saving your most recent configurations.

R2(config-archive)#time-period ?
  <1-525600>  Number of minutes to wait between archive creation
R2(config-archive)#time-period 1

time-period  delays the time after an archive creation has been triggered, meaning that if you issued a write  command it doesn't create the archive until the configured time has passed. it's a trade off really, since you can write 20 lines manually or 500 lines pasted from the notepad in that minute and you might need to rollback all of that before the minute is off. no putting this command will just create the archive instantaneously.

let's see how our configuration works so far

 R2#show archive
The maximum archive configurations allowed is 14.
The next archive file will be named disk0:/archives/backup-0
 Archive #  Name
   1      
   2      
   3      
   4      
   5      
   6      
   7      
   8      
   9      
   10
There are currently no configuration saved.

there are no archives saved right now, how about configuring an IP address then saving it. You can actually do this in two ways, either configuring write-memory under the achrive hierarchy or by simply issuing the archive config in the exec mode

 R2#conf tEnter configuration commands, one per line.  End with CNTL/Z.R2(config)#int f0/0R2(config-if)#ip add 10.1.2.1 255.255.255.0R2(config-if)#endR2#writeBuilding configuration...[OK]

R2#show archive
The maximum archive configurations allowed is 14.
There are currently 1 archive configurations saved.
The next archive file will be named disk0:/archives/backup-1
 Archive #  Name
   1        disk0:/archives/backup-0 <- Most Recent
   2      
   3      
   4      
   5      
   6      
   7      
   8      
   9      
   10   

As you can see, the router saved this configuration with the name backup-0 in disk0. lets change the hostname also and make a new archive

R2(config)#hostname cisco-router
cisco-router(config)#end
cisco-router#wr
Building configuration...
*Jun 10 00:52:25.715: %SYS-5-CONFIG_I: Configured from console by console[OK]
cisco-router#show archive
The maximum archive configurations allowed is 14.

There are currently 2 archive configurations saved.

The next archive file will be named disk0:/archives/backup-2

Archive # Name
1 disk0:/archives/backup-0
2 disk0:/archives/backup-1 <- Most Recent
3
4
5
6
7
8
9
10

cisco-router#

excellent eh? now how can you actually see the contents of that configuration, it has been a whilke and you actually can't remember which one you changed the interface IP address in 

you can do that in many way actually, the simplest of them is using the more  command from the exec mode

cisco-router#more disk0:/archives/backup-0

This will show you the whole configuration that is in backup-0 which is very cumbersome to compare with any other config. 

cisco-router#show archive config differences disk0:/archives/backup-0!Contextual Config Diffs:+hostname R2-hostname cisco-router

Notice the (+) and (-) in-front of the hostname lines here, this basically means that the archive your viewing right now contains hostname R2 and  and does not contain hostname cisco-router. it's very neat specially when your comparing your current configuration with an archived one to assess the impact of rolling back.

now we saved the configuration, how do we rollback to this configuration. There are several ways to do this

let's see what our disk contains first

cisco-router#dir disk0:/archivesDirectory of disk0:/archives/
    2  -rw-        1748  Jun 10 2013 00:47:54 +00:00  backup-0 

    3  -rw-        1758  Jun 10 2013 00:52:26 +00:00  backup-1
66875392 bytes total (66863104 bytes free)

As expected, the configurations saved in the disk0 with base name backup. we can load these configs to the routers with several techniques which are fairly different in behavior

• making the archive file the startup-config file! you can do as follow reloading the router, when the router comes up, it will use the configuration was that copied to the startup config, which is not very pretty in downtime prospective. 

 copy disk0:/archives/backup-0 startup-config

• using the configure replace command we talked about earlier, which is better because it replaces the  running configuration with any complete configuration saved on your flash or disk configure 

replace disk0:/archives/backup-0 force

Hopefully i managed to cover the basics of archiving, there's more and as usual old articles are updated with new stuff every now and then. Please feel free to comment regarding any mistakes or new features!