I like playing with routers

Juniper OSPF Discontiguous Backbone (Virtual-Links)

2012-02-05T11:34:00.001+10:00

Note: This is blog post is part of a series of articles dealing with Juniper Junos rather than Cisco IOS which is what some readers may be expecting.

Traffic cannot traverse different ospf areas without going through the OSPF backbone and OSPF expects that the backbone area (area 0) is contiguous. OSPF area membership is interface/link based.

So it is possible to use some kind of virtual technique to logically extend the OSPF backbone. One of the tools in our toolbox is "virtual-links" which uses a non-backbone area to provide transit capability to an OSPF ABR.

In this example:

R1 is an ABR with lo0.0 in area 0 and em1.12 in area 12
R2 is a normal router with lo0.0 and em1.12 in area 12, with em1.23 in area 23
R3 is a normal router with lo0.0 and em1.23 in area 23

The starting configs are shown below:

R1 (ABR OSPF Area 0 / 23)
root@R1> show configuration | display set
set system host-name R1
set interfaces em1 vlan-tagging
set interfaces em1 unit 12 vlan-id 12
set interfaces em1 unit 12 family inet address 10.1.12.1/24
set interfaces lo0 unit 0 family inet address 1.1.1.1/32
set routing-options router-id 1.1.1.1
set protocols ospf area 0.0.0.0 interface lo0.0
set protocols ospf area 0.0.0.12 interface em1.12

R2 (OSPF Area 12 / 23)
root@R2> show configuration | display set
set system host-name R2
set interfaces em1 vlan-tagging
set interfaces em1 unit 12 vlan-id 12
set interfaces em1 unit 12 family inet address 10.1.12.2/24
set interfaces em1 unit 23 vlan-id 23
set interfaces em1 unit 23 family inet address 10.1.23.2/24
set interfaces lo0 unit 0 family inet address 2.2.2.2/32
set routing-options router-id 2.2.2.2
set protocols ospf area 0.0.0.12 interface em1.12
set protocols ospf area 0.0.0.23 interface em1.23
set protocols ospf area 0.0.0.12 interface lo0.0

R3 (OSPF Area 12 / 23)
root@R3> show configuration | display set
set system host-name R3
set interfaces em1 vlan-tagging
set interfaces em1 unit 23 vlan-id 23
set interfaces em1 unit 23 family inet address 10.1.23.3/24
set interfaces lo0 unit 0 family inet address 3.3.3.3/32
set routing-options router-id 3.3.3.3
set protocols ospf area 0.0.0.0 interface lo0.0
set protocols ospf area 0.0.0.23 interface em1.23

Let's verify OSPF is up and running and we have neighbors

root@R1> show ospf interface
Interface           State   Area            DR ID           BDR ID          Nbrs
lo0.0               DR      0.0.0.0         1.1.1.1         0.0.0.0            0
em1.12              BDR     0.0.0.12        1.1.1.1         2.2.2.2            1

root@R2> show ospf interface
Interface           State   Area            DR ID           BDR ID          Nbrs
em1.23              BDR      0.0.0.23        2.2.2.2         3.3.3.3            1
em1.12              DR      0.0.0.12        1.1.1.1         2.2.2.2            1
lo0.0               DR      0.0.0.12        2.2.2.2         0.0.0.0            0

root@R3> show ospf interface
Interface           State   Area            DR ID           BDR ID          Nbrs
em1.23              DR      0.0.0.23        2.2.2.2         3.3.3.3            1
lo0.0               DR      0.0.0.23        3.3.3.3         0.0.0.0            0

now check the routing table on R1 and R3

root@R1> show route terse

inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

A Destination        P Prf   Metric 1   Metric 2 Next hop        AS path
* 1.1.1.1/32         D   0                       >lo0.0
* 2.2.2.2/32         O 10          1            >10.1.12.2
* 10.1.12.0/24       D   0                       >em1.12
* 10.1.12.1/32       L   0                        Local
* 10.1.23.0/24       O 10          2            >10.1.12.2
* 224.0.0.5/32       O 10          1             MultiRecv

root@R3> show route terse

inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

A Destination        P Prf   Metric 1   Metric 2 Next hop        AS path
* 2.2.2.2/32         O 10          1            >10.1.23.2
* 3.3.3.3/32         D   0                       >lo0.0
* 10.1.12.0/24       O 10          2            >10.1.23.2
* 10.1.23.0/24       D   0                       >em1.23
* 10.1.23.3/32       L   0                        Local
* 224.0.0.5/32       O 10          1             MultiRecv
On R1, we cant see a route for 3.3.3.3/32 which is in OSPF Area 23, and on R3, we cant see a route for 1.1.1.1/32 which is in OSPF Area 0, since the connectivity between R1 and R3 traverses OSPF area 12.

To resolve this using virtual-links we need to add the virtual-link configuration to OSPF area 0 (this is implemented differently to the way IOS does it but personally I think this makes it much clearer as to what the configuration is doing, which is extending OSPF 0 to a new ABR)

root@R1> configure
Entering configuration mode

[edit]
root@R1# set protocols ospf area 0 virtual-link neighbor-id 2.2.2.2 transit-area 12
[edit]
root@R1# commit and-quit
commit complete
Exiting configuration mode

root@R2> configure
Entering configuration mode

[edit]
root@R2# set protocols ospf area 0 virtual-link neighbor-id 1.1.1.1 transit-area 12
[edit]
root@R2# commit and-quit
commit complete
Exiting configuration mode

Just to show what the OSPF config on R1 and R2 now looks like

root@R1> show configuration protocols ospf
area 0.0.0.0 {
    virtual-link neighbor-id 2.2.2.2 transit-area 0.0.0.12;
    interface lo0.0;
}
area 0.0.0.12 {
    interface em1.12;
}

root@R2> show configuration protocols ospf
area 0.0.0.23 {
    interface em1.23;
}
area 0.0.0.12 {
    interface lo0.0;
    interface em1.12;
}
area 0.0.0.0 {
    virtual-link neighbor-id 1.1.1.1 transit-area 0.0.0.12;
}

The virtual-link configuration establishes an on-demand point-to-point link

root@R1> show ospf interface
Interface           State   Area            DR ID           BDR ID          Nbrs
lo0.0               DR      0.0.0.0         1.1.1.1         0.0.0.0            0
vl-2.2.2.2          PtToPt 0.0.0.0         0.0.0.0         0.0.0.0            1
em1.12              BDR     0.0.0.12        2.2.2.2         1.1.1.1            1

root@R2> show ospf interface
Interface           State   Area            DR ID           BDR ID          Nbrs
em1.23              BDR     0.0.0.23        3.3.3.3         2.2.2.2            1
em1.12              DR      0.0.0.12        2.2.2.2         1.1.1.1            1
lo0.0               DR      0.0.0.12        2.2.2.2         0.0.0.0            0
vl-1.1.1.1          PtToPt 0.0.0.0         0.0.0.0         0.0.0.0            1

Let's check that R1 and R3 now have visibility of each others loopbacks in the routing table:

root@R1> show route terse

inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

A Destination        P Prf   Metric 1   Metric 2 Next hop        AS path
* 1.1.1.1/32         D   0                       >lo0.0
* 2.2.2.2/32         O 10          1            >10.1.12.2
* 3.3.3.3/32         O 10          2            >10.1.12.2
* 10.1.12.0/24       D   0                       >em1.12
* 10.1.12.1/32       L   0                        Local
* 10.1.23.0/24       O 10          2            >10.1.12.2
* 224.0.0.5/32       O 10          1             MultiRecv

root@R3> show route terse

inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

A Destination        P Prf   Metric 1   Metric 2 Next hop        AS path
* 1.1.1.1/32         O 10          2            >10.1.23.2
* 2.2.2.2/32         O 10          1            >10.1.23.2
* 3.3.3.3/32         D   0                       >lo0.0
* 10.1.12.0/24       O 10          2            >10.1.23.2
* 10.1.23.0/24       D   0                       >em1.23
* 10.1.23.3/32       L   0                        Local
* 224.0.0.5/32       O 10          1             MultiRecv

Yes, lets verify IP connectivity

root@R1> ping 3.3.3.3 source 1.1.1.1 count 3
PING 3.3.3.3 (3.3.3.3): 56 data bytes
64 bytes from 3.3.3.3: icmp_seq=0 ttl=63 time=7.210 ms
64 bytes from 3.3.3.3: icmp_seq=1 ttl=63 time=2.663 ms
64 bytes from 3.3.3.3: icmp_seq=2 ttl=63 time=2.657 ms

--- 3.3.3.3 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.657/4.177/7.210/2.145 ms

Success!

Juniper OSPF Inter-Area Filtering

2012-02-04T16:56:00.000+10:00

Right now I'm on a bit of a break with my CCIE studies but I'm still playing with routers. As it's been a little while since I've played with Junos and I'm planning on attempting the JNCIP-SP in the next couple of months, I have been getting familiar again using Olives which will really only allow a subset of the blueprint to be tested because things like QoS and VPLS cant really be tested on it but it's still quite a reasonable platform. I'm not going to discuss much on Olives, there is plenty of guides and so on available which your favourite search engine may assist with.

For those people interested in learning Junos but are really only have an IOS background. There is some free online training material from Juniper called Junos as a Second Language

The routers I'm playing with at the moment have all have interface em1 connected to the same virtual switch. Point to point links are established using VLANs. R3 is the OSPF ABR with only it's loopback interface in OSPF Area 0

R1 (OSPF Area 13)
root@R1> show configuration | display set
set system host-name R1
set interfaces em1 vlan-tagging
set interfaces em1 unit 13 vlan-id 13
set interfaces em1 unit 13 family inet address 10.1.13.1/24
set interfaces lo0 unit 0 family inet address 1.1.1.1/32
set routing-options router-id 1.1.1.1
set protocols ospf area 0.0.0.13 interface lo0.0
set protocols ospf area 0.0.0.13 interface em1.13

R2 (OSPF Area 23)
root@R2> show configuration | display set
set system host-name R2
set interfaces em1 vlan-tagging
set interfaces em1 unit 23 vlan-id 23
set interfaces em1 unit 23 family inet address 10.1.23.2/24
set interfaces lo0 unit 0 family inet address 2.2.2.2/32
set routing-options router-id 2.2.2.2
set protocols ospf area 0.0.0.23 interface em1.23
set protocols ospf area 0.0.0.23 interface lo0.0

R3 (ABR)
root@R3> show configuration | display set
set system host-name R3
set interfaces em1 vlan-tagging
set interfaces em1 unit 13 vlan-id 13
set interfaces em1 unit 13 family inet address 10.1.13.3/24
set interfaces em1 unit 23 vlan-id 23
set interfaces em1 unit 23 family inet address 10.1.23.3/24
set interfaces lo0 unit 0 family inet address 3.3.3.3/32
set routing-options router-id 3.3.3.3
set protocols ospf area 0.0.0.0 interface lo0.0
set protocols ospf area 0.0.0.13 interface em1.13
set protocols ospf area 0.0.0.23 interface em1.23

Let's check that our adjacencies are up:

root@R1> show ospf neighbor
Address          Interface              State     ID               Pri  Dead
10.1.13.3        em1.13                 Full      3.3.3.3          128    39

root@R2> show ospf neighbor
Address          Interface              State     ID               Pri  Dead
10.1.23.3        em1.23                 Full      3.3.3.3          128    36

root@R3> show ospf neighbor
Address          Interface              State     ID               Pri Dead
10.1.23.2        em1.23                 Full      2.2.2.2          128    34
10.1.13.1        em1.13                 Full      1.1.1.1          128    34

Lets have a look at the routing table and ospf databases

root@R1> show route terse

inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

A Destination        P Prf   Metric 1   Metric 2 Next hop        AS path
* 1.1.1.1/32         D   0                       >lo0.0
* 2.2.2.2/32         O 10          2            >10.1.13.3
* 3.3.3.3/32         O 10          1            >10.1.13.3
* 10.1.13.0/24       D   0                       >em1.13
* 10.1.13.1/32       L   0                        Local
* 10.1.23.0/24       O 10          2            >10.1.13.3
* 224.0.0.5/32       O 10          1             MultiRecv

In this mode which is the basic way to see the routing table, we cant tell what kind of OSPF routes are present as we can in IOS - however there's a different command "show ospf route" which can help out in that regard:

root@R1> show ospf route
Topology default Route Table:

Prefix             Path Route      NH       Metric NextHop       Nexthop
                   Type Type       Type            Interface     Address/LSP
3.3.3.3            Intra Area BR    IP            1 em1.13        10.1.13.3
1.1.1.1/32         Intra Network    IP            0 lo0.0
2.2.2.2/32         Inter Network    IP            2 em1.13        10.1.13.3
3.3.3.3/32         Inter Network    IP            1 em1.13        10.1.13.3
10.1.13.0/24       Intra Network    IP            1 em1.13
10.1.23.0/24       Inter Network    IP            2 em1.13        10.1.13.3

root@R2> show ospf route
Topology default Route Table:

Prefix             Path  Route      NH       Metric NextHop       Nexthop
                   Type  Type       Type            Interface     Address/LSP
3.3.3.3            Intra Area BR    IP            1 em1.23        10.1.23.3
1.1.1.1/32         Inter Network    IP            2 em1.23        10.1.23.3
2.2.2.2/32         Intra Network    IP            0 lo0.0
3.3.3.3/32         Inter Network    IP            1 em1.23        10.1.23.3
10.1.13.0/24       Inter Network    IP            2 em1.23        10.1.23.3
10.1.23.0/24       Intra Network    IP            1 em1.23

root@R3> show ospf route
Topology default Route Table:

Prefix             Path Route      NH       Metric NextHop       Nexthop
                   Type Type       Type            Interface     Address/LSP
1.1.1.1            Intra Router     IP            1 em1.13        10.1.13.1
2.2.2.2            Intra Router     IP            1 em1.23        10.1.23.2
1.1.1.1/32         Intra Network    IP            1 em1.13        10.1.13.1
2.2.2.2/32         Intra Network    IP            1 em1.23        10.1.23.2
3.3.3.3/32         Intra Network    IP            0 lo0.0
10.1.13.0/24       Intra Network    IP            1 em1.13
10.1.23.0/24       Intra Network    IP            1 em1.23

The "show ospf route" command are from the router's point of view. When the router is an OSPF ABR because we are serving multiple areas, what is considered an intra network route may be correct for one area, while being inter-network routes for other areas and therfore the "show ospf database" may be of more help here.

root@R3> show ospf database

    OSPF database, Area 0.0.0.0
Type       ID               Adv Rtr           Seq      Age Opt Cksum Len
Router *3.3.3.3          3.3.3.3          0x80000004    36 0x22 0x67a3 36
Summary *1.1.1.1          3.3.3.3          0x80000002    36 0x22 0x922   28
Summary *2.2.2.2          3.3.3.3          0x80000003    36 0x22 0xd84d 28
Summary *10.1.13.0        3.3.3.3          0x80000003    36 0x22 0x17fe 28
Summary *10.1.23.0        3.3.3.3          0x80000021    35 0x22 0x6c81 28

    OSPF database, Area 0.0.0.13
Type       ID               Adv Rtr           Seq      Age Opt Cksum Len
Router   1.1.1.1          1.1.1.1          0x80000007    37 0x22 0x6973 48
Router *3.3.3.3          3.3.3.3          0x80000007    36 0x22 0x2eaf 36
Network *10.1.13.3        3.3.3.3          0x80000003    36 0x22 0x9d63 32
Summary *2.2.2.2          3.3.3.3          0x80000003    36 0x22 0xd84d 28
Summary *3.3.3.3          3.3.3.3          0x80000003    36 0x22 0xa082 28
Summary *10.1.23.0        3.3.3.3          0x80000006    35 0x22 0xa266 28

    OSPF database, Area 0.0.0.23
Type       ID               Adv Rtr           Seq      Age Opt Cksum Len
Router   2.2.2.2          2.2.2.2          0x8000002e    37 0x22 0xc88   48
Router *3.3.3.3          3.3.3.3          0x8000002c    36 0x22 0xc0e3 36
Network *10.1.23.3        3.3.3.3          0x80000002    36 0x22 0x6390 32
Summary *1.1.1.1          3.3.3.3          0x80000002    36 0x22 0x922   28
Summary *3.3.3.3          3.3.3.3          0x80000003    36 0x22 0xa082 28
Summary *10.1.13.0        3.3.3.3          0x80000003    36 0x22 0x17fe 28

Lets add an extra internal network on R1 to be advertised in OSPF - we can do this by adding another IP Address on the loopback interface.

root@R1> configure
Entering configuration mode

[edit]
root@R1# set interfaces lo0 unit 0 family inet address 111.111.111.111/24
root@R1# commit and-quit

root@R1> show route terse | match 111
* 111.111.111.0/24   D   0                       >lo0.0
* 111.111.111.111/32 L   0                        Local

root@R2> show route terse | match 111
* 111.111.111.0/24   O 10          2            >10.1.23.3
* 111.111.111.111/32 O 10          2            >10.1.23.3

Seeing two routes associated was a little unexpected, however I suspect this is due to the type "L" local route.

Interestingly Junos appears to advertise both of these into OSPF rather than treating the loopback interface with a network mask the same as a host route (as per page 128 of RFC2328) - it seems to do a bit of a hybrid of the point-to-point network type and host-route

root@R1> show ospf database router lsa-id 1.1.1.1 detail

    OSPF database, Area 0.0.0.13
Type       ID               Adv Rtr           Seq      Age Opt Cksum Len
Router *1.1.1.1          1.1.1.1          0x8000000c   463 0x22 0xb6f4 72
bits 0x0, link count 4
id 10.1.13.3, data 10.1.13.1, Type Transit (2)
    Topology count: 0, Default metric: 1
id 1.1.1.1, data 255.255.255.255, Type Stub (3)
    Topology count: 0, Default metric: 0
id 111.111.111.111, data 255.255.255.255, Type Stub (3)
    Topology count: 0, Default metric: 0
id 111.111.111.0, data 255.255.255.0, Type Stub (3)
    Topology count: 0, Default metric: 0
Topology default (ID 0)
    Type: Transit, Node ID: 10.1.13.3
      Metric: 1, Bidirectional

If we specifically set the ospf network interface type of the loopback to to point-to-point maybe that brings things back to what I would expect to see.

root@R1> configure
Entering configuration mode

[edit]
root@R1# set protocols ospf area 13 interface lo0.0 interface-type p2p

[edit]
root@R1# show protocols ospf
area 0.0.0.13 {
    interface lo0.0 {
        interface-type p2p;
    }
    interface em1.13;
}

[edit]
root@R1# commit and-quit
commit complete
Exiting configuration mode
root@R1> show ospf database router lsa-id 1.1.1.1 detail

    OSPF database, Area 0.0.0.13
Type       ID               Adv Rtr           Seq      Age Opt Cksum Len
Router *1.1.1.1          1.1.1.1          0x8000000e    25 0x22 0x3d3a 60
bits 0x0, link count 3
id 10.1.13.3, data 10.1.13.1, Type Transit (2)
    Topology count: 0, Default metric: 1
id 111.111.111.0, data 255.255.255.0, Type Stub (3)
    Topology count: 0, Default metric: 0
id 1.1.1.1, data 255.255.255.255, Type Stub (3)
    Topology count: 0, Default metric: 0
Topology default (ID 0)
    Type: Transit, Node ID: 10.1.13.3
      Metric: 1, Bidirectional

root@R2> show ospf database netsummary

    OSPF database, Area 0.0.0.23
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Summary  1.1.1.1          3.3.3.3          0x80000004  1073  0x22 0x524   28
Summary  3.3.3.3          3.3.3.3          0x80000004  1091  0x22 0x9e83  28
Summary  10.1.13.0        3.3.3.3          0x80000004   905  0x22 0x15ff  28
Summary  111.111.111.0    3.3.3.3          0x80000001  1073  0x22 0x8d54  28
 

root@R2> show route terse | match 111
* 111.111.111.0/24   O 10          2            >10.1.23.3

Yes it does. Okay now things are as expected, now lets filter the 111.111.111.0/24 route from appearing in R2's routing table and ospf database.

Lets check the OSPF database for the different area on the ABR with the summary routes for 111.111.111.0/24

root@R3> show ospf database | match "Area|111"
    OSPF database, Area 0.0.0.0
Summary *111.111.111.0    3.3.3.3          0x80000001 1428 0x22 0x8d54 28
    OSPF database, Area 0.0.0.13
    OSPF database, Area 0.0.0.23
Summary *111.111.111.0    3.3.3.3          0x80000001 1428 0x22 0x8d54 28

Inter-Area filtering can be done to limit the flow of Type 3 (Summary) LSAs on the ABR using routing policy, in this case we will be stopping 111.111.111.0/24 from being exported from OSPF Area 0 into OSPF Area 23:

root@R3> configure
Entering configuration mode

[edit]
root@R3# set policy-options policy-statement ToArea23 term 10 from route-filter 111.111.111.0/24 exact
root@R3# set policy-options policy-statement ToArea23 term 10 then reject
root@R3# set policy-options policy-statement ToArea23 term 20 then accept
root@R3# set protocols ospf area 0.0.0.23 network-summary-export ToArea23
root@R3# commit and-quit

Let's make sure the ABR still has the route available

root@R3> show route terse 111.111.111.0/24

inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

A Destination        P Prf   Metric 1   Metric 2 Next hop        AS path
* 111.111.111.0/24   O 10          1            >10.1.13.1

And lets compare the ospf database output and see if 111.111.111.0/24 is no longer in area 23

root@R3> show ospf database | match "Area|111"
    OSPF database, Area 0.0.0.0
Summary *111.111.111.0    3.3.3.3          0x80000001 1546 0x22 0x8d54 28
    OSPF database, Area 0.0.0.13
    OSPF database, Area 0.0.0.23

Nope, one last final verification

root@R2> show route terse 111.111.111.0/24

root@R2> show ospf database netsummary

    OSPF database, Area 0.0.0.23
Type       ID               Adv Rtr           Seq      Age Opt Cksum Len
Summary 1.1.1.1          3.3.3.3          0x80000004 1547 0x22 0x524   28
Summary 3.3.3.3          3.3.3.3          0x80000004 1565 0x22 0x9e83 28
Summary 10.1.13.0        3.3.3.3          0x80000004 1379 0x22 0x15ff 28

Cool. So we've tried an export policy, lets quickly test an import policy doing a similar job. This time lets add 222.222.222.222/16 to R2's loopback and stop it from being advertised to R1.

root@R2> configure
Entering configuration mode

[edit]
root@R2# set interfaces lo0 unit 0 family inet address 222.222.222.222/16

root@R2# set protocols ospf area 23 interface lo0.0 interface-type p2p

root@R2# commit and-quit

root@R1> show route terse | match 222
* 222.222.0.0/16     O  10          2            >10.1.13.3

root@R3> show ospf database | match "Area|222"

    OSPF database, Area 0.0.0.0
Summary *222.222.0.0      3.3.3.3          0x80000001     5  0x22 0x75fc  28
    OSPF database, Area 0.0.0.13
Summary *222.222.0.0      3.3.3.3          0x80000001     5  0x22 0x75fc  28
    OSPF database, Area 0.0.0.23

root@R3> show ospf database router lsa-id 2.2.2.2 detail

    OSPF database, Area 0.0.0.23
Type       ID               Adv Rtr           Seq      Age Opt Cksum Len
Router   2.2.2.2          2.2.2.2          0x80000032 1292 0x22 0x7052 60
bits 0x0, link count 3
id 10.1.23.3, data 10.1.23.2, Type Transit (2)
    Topology count: 0, Default metric: 1
id 2.2.2.2, data 255.255.255.255, Type Stub (3)
    Topology count: 0, Default metric: 0
id 222.222.0.0, data 255.255.0.0, Type Stub (3)
    Topology count: 0, Default metric: 0
Topology default (ID 0)
    Type: Transit, Node ID: 10.1.23.3
      Metric: 1, Bidirectional

In this case, we're using an import policy on the ABR to stop the route associated Type 1 LSA from being turned into a Type 3 LSA

root@R3> configure
Entering configuration mode

[edit]
root@R3# set policy-options policy-statement FromArea23 term 10 from route-filter 222.222.0.0/16 exact
root@R3# set policy-options policy-statement FromArea23 term 10 then reject
root@R3# set policy-options policy-statement FromArea23 term 20 then accept
root@R3# set protocols ospf area 0.0.0.23 network-summary-import FromArea23

root@R2# commit and-quit

Let's make sure the ABR still has the route (which it will have due to one of the interfaces being in OSPF area 23)

root@R3> show route terse | match 222
* 222.222.0.0/16     O 10          1            >10.1.23.2

Now lets see if there are any Type 3 LSAs associated with 222.222.0.0/16

root@R3> show ospf database | match "Area|222"
    OSPF database, Area 0.0.0.0
    OSPF database, Area 0.0.0.13
    OSPF database, Area 0.0.0.23

Nope - our policy is doing it's job, so there shouldn't be a route for 222.222.0.0/16 on R1 either:

root@R1> show route terse | match 222

Which is what we wanted to see.

So there you go.

Signs of Life

2012-02-04T15:08:00.002+10:00

It's been a few months since my last posting. Some may have been aware that in December 2011, I was going to give the R&S Lab another shot. Unfortunately for me I didn't end up achieving my number at that time. Unlike my other attempts where the troubleshooting component was my bugbear, this time I was able to pass that section, I'm sure that the Cisco 360 labs in that regard definitely helped me to get over that hurdle. This time however it was the config section where I dropped my game. To say it was a little discouraging is not wrong, however at the very least I came out finally getting the TS curse of my back - it just needs me to be able to pass TS and Config at the same time, which I will do at some stage.

After that lab attempt, with my focus primarily being on work and study for quite a period of time, I knew I needed a bit of a break but also my very supportive wife needed to get to know me again. It doesn't by any stretch mean that I have given up, actually I have been still playing around with routers (I do a bit of that in my day job) and I've been keeping my studies up for non-Cisco related certs. In actual fact I strongly believe the study that I have done for the CCIE helps regardless of the vendor because generally the protocol operation is the same across equipment, its more the CLI syntax is a bit different. Recently I passed one of the exams that will contribute to me getting the Alcatel-Lucent 3RP with only 1 more exam left to obtain that. Also my Juniper JNCIS-M is expiring in a few months and since the M/T series track has been superseded with the SP track, I'm considering upgrading to the JNCIP-SP since this exam is now a computer based rather than a hands on exam.

So I'm not 100% sure exactly when I will get back on the CCIE Lab horse but perhaps around April.

BGP Route Aggregation with AS-SET

2011-11-19T14:48:00.001+10:00

This little scenario involves 3 routers (R1, R2 and R3) R1 (AS 1) and R2 (AS 2) are directly connected via Frame Relay. R2 is directly connected to R3 (AS 3) via Frame Relay as well but R3 is an uncontrolled device (in the CCIE Lab this could be a Backbone router) and we plan on aggregating routes R2 learns from R3 so R1 has a more manageable routing table.

The configs are pretty simple (R3's config wont be displayed until the end but it can be inferred as we go along)

hostname R1
interface Serial0/0
no ip address
encapsulation frame-relay
no frame-relay inverse-arp
interface Serial0/0.12 point-to-point
ip address 10.1.12.1 255.255.255.0
frame-relay interface-dlci 102
router bgp 1
no synchronization
neighbor 10.1.12.2 remote-as 2
no auto-summary

hostname R2
interface Serial0/0
no ip address
encapsulation frame-relay
no frame-relay inverse-arp
interface Serial0/0.21 point-to-point
ip address 10.1.12.2 255.255.255.0
frame-relay interface-dlci 201
interface Serial0/0.23 point-to-point
ip address 10.1.23.2 255.255.255.0
frame-relay interface-dlci 203
router bgp 2
no synchronization
neighbor 10.1.12.1 remote-as 1
neighbor 10.1.23.3 remote-as 3
no auto-summary

So let's start off with with R2 sees from R3

R2#sh ip bgp | b Network
   Network          Next Hop            Metric LocPrf Weight Path
*> 172.168.0.0/24   10.1.23.3                0             0 3 ?
*> 172.168.1.0/24   10.1.23.3                0             0 3 ?
*> 172.168.2.0/24   10.1.23.3                0             0 3 ?
*> 172.168.3.0/24   10.1.23.3                0             0 3 ?
*> 172.199.0.0/24   10.1.23.3                0             0 3 ?
*> 172.199.1.0/24   10.1.23.3                0             0 3 ?
*> 172.199.2.0/24   10.1.23.3                0             0 3 ?
*> 172.199.3.0/24   10.1.23.3                0             0 3 ?

So let's aggregate these for R1 so it only sees the summary routes

R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#router bgp 2
R2(config-router)#aggregate-address 172.199.0.0 255.255.252.0 summary-only
R2(config-router)#aggregate-address 172.168.0.0 255.255.252.0 summary-only
R2(config-router)#end

Let's see what R1 now sees

R1>sh ip bgp | b Network
   Network          Next Hop            Metric LocPrf Weight Path
*> 172.168.0.0/22   10.1.12.2                0             0 2 i
*> 172.199.0.0/22   10.1.12.2                0             0 2 i

Alright, we can see the two aggregate routes, however we see that the AS-PATH shows R2 as the originator. What if we wanted to see that these originated from R3?

Within the aggregate-address command, we can include the AS-SET option, which will show us the Autonomous Systems in the path which contribute to this route

R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#router bgp 2
R2(config-router)#aggregate-address 172.168.0.0 255.255.252.0 summary-only as-set
R2(config-router)#aggregate-address 172.199.0.0 255.255.252.0 summary-only as-set
R2(config-router)#end

So now let's see what R1 sees:

R1>sh ip bgp | b Network
Network Next Hop Metric LocPrf Weight Path
*> 172.199.0.0/22 10.1.12.2 0 0 2 3 ?

Now this is a little odd, we can see that the route that is present does now indeed include the full AS-Path, however we have lost the route for 172.168.0.0/22 even though we previously had it. Maybe R2 is doing something wrong?

R2#show ip bgp neighbor 10.1.12.1 advertised-routes
BGP table version is 21, local router ID is 10.1.23.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 172.199.0.0/22   0.0.0.0                       100 32768 3 ?

Hello 172.168.0.0/22? Have we lost it?

R2#sh ip bgp | b Network
   Network          Next Hop            Metric LocPrf Weight Path
s> 172.168.0.0/24   10.1.23.3                0             0 3 ?
*> 172.168.0.0/22   0.0.0.0                       100 32768 3 ?
s> 172.168.1.0/24   10.1.23.3                0             0 3 ?
s> 172.168.2.0/24   10.1.23.3                0             0 3 ?
s> 172.168.3.0/24   10.1.23.3                0             0 3 ?
s> 172.199.0.0/24   10.1.23.3                0             0 3 ?
*> 172.199.0.0/22   0.0.0.0                       100 32768 3 ?
s> 172.199.1.0/24   10.1.23.3                0             0 3 ?
s> 172.199.2.0/24   10.1.23.3                0             0 3 ?
s> 172.199.3.0/24   10.1.23.3                0             0 3 ?

No, something must have happened to stop us sending things it on to R1 though.

R2#show ip bgp 172.168.0.0/22
BGP routing table entry for 172.168.0.0/22, version 20
Paths: (1 available, best #1, table Default-IP-Routing-Table, not advertised to EBGP peer)
Not advertised to any peer
3, (aggregated by 2 10.1.23.2)
    0.0.0.0 from 0.0.0.0 (10.1.23.2)
      Origin incomplete, localpref 100, weight 32768, valid, aggregated, local, best
      Community: no-export

When the AS-SET parameter is used, the communities of the contributing routes are also attached to the aggregate, at least one of these contributing routes must have had the no-export community attached to it.

R2#show ip bgp community no-export
BGP table version is 21, local router ID is 10.1.23.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
s> 172.168.0.0/24   10.1.23.3                0             0 3 ?
*> 172.168.0.0/22   0.0.0.0                       100 32768 3 ?
s> 172.168.2.0/24   10.1.23.3                0             0 3 ?

So if we would like to ignore R3's instruction of no-export to R1 while maintaining the AS-Path, we have to use our favourite IOS swiss-army knife also known as the route-map which in this form will be used as an attribute map to remove any communities on the aggregate which would normally be inherited from contributing routes:

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#route-map NoAttributes
R2(config-route-map)#set community none
R2(config-route-map)#router bgp 2
R2(config-router)#aggregate-address 172.168.0.0 255.255.252.0 summary-only as-set attribute-map NoAttributes
R2(config-router)#end

So let's check that this now works

R2#show ip bgp community no-export
BGP table version is 22, local router ID is 10.1.23.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
s> 172.168.0.0/24   10.1.23.3                0             0 3 ?
s> 172.168.2.0/24   10.1.23.3                0             0 3 ?

172.168.0.0/22 is no longer in this list, so it appears that this should be resolved:

R2#sh ip bgp nei 10.1.12.1 advertised-routes
BGP table version is 22, local router ID is 10.1.23.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 172.168.0.0/22   0.0.0.0                       100 32768 3 ?
*> 172.199.0.0/22   0.0.0.0                       100 32768 3 ?

Total number of prefixes 2

R1>sh ip bgp | b Network
   Network          Next Hop            Metric LocPrf Weight Path
*> 172.168.0.0/22   10.1.12.2                0             0 2 3 ?
*> 172.199.0.0/22   10.1.12.2                0             0 2 3 ?

Success!

R3 Config for reference:

hostname R3
interface Serial0/0
no ip address
encapsulation frame-relay
no frame-relay inverse-arp
interface Serial0/0.32 point-to-point
ip address 10.1.23.3 255.255.255.0
frame-relay interface-dlci 302
router bgp 3
no synchronization
redistribute static
neighbor 10.1.23.2 remote-as 2
neighbor 10.1.23.2 send-community
neighbor 10.1.23.2 route-map R2-OUT out
no auto-summary
route-map R2-OUT permit 10
match ip address 1
set community no-export
route-map R2-OUT permit 20
access-list 1 permit 172.168.0.0 0.0.254.255

Cisco 360 Assessment Lab Review

2011-11-19T14:14:00.001+10:00

Troubleshooting has been the major area in the lab exam that I have needed help in lifting my game. I have used resources in multiple areas to give assistance and they have all helped improve my performance but I have been searching for that extra push to get there. As previously mentioned I gave the Netmaster class updated assessment labs a spin and to be honest I found particularly in the troubleshooting area that this is the best I've come up against to simulate what you get in the real lab.

The NMC Lab is split into two parts - Troubleshooting and Configuration. The Troubleshooting section is newer and handled differently to how the Configuration section appears. To access the TS lab, you have to install a Cisco VPN client (the instructions you are sent a day or two before your actual sessions starts includes a download link for the VPN client as well as a test account to validate that you can connect) Also included are recommendations to configure your web browser and telnet client which will make things easier so you can click on a router and have putty (or securecrt if that's your poison) fire up

Once your session has begun and you have connected to the VPN, you go to a web page which has the tickets and the network diagrams. The major difference is that there appears to be 3 hours allocated for TS rather than 2. I used a timer to force myself to stop after 2 hours to make it as real as possible. The troubleshooting section is based on the Cisco IOU platform and supports approximately 30 routers. Unlike the actual lab exam, this doesn't include simulated catalyst platforms, so it's not 100% accurate but is close enough for the majority of tickets you might actually encounter in the real thing and appears to cover all of the technologies in the blueprint. The types of questions in this simulation are actually more vague than what I recall seeing in the actual lab itself which can be a little annoying, however if you can deal with those you will probably find the actual lab a bit easier.

The configuration section in the lab was a 6 hour configuration section using real routers and switches. The copyright date of the exam was 2009 and the presentation was not web based - the questions were in a PDF file. Although the actual config lab these days is usable via a web interface to read questions/see diagrams and no printed material is given, I would actually recommend that you print the configuration section questions out so you can get easy reference to the diagrams otherwise there will be a lot of scrolling up and down. I found the config lab to be a nice challenge and I guess of similar level to what I have encountered in the real lab.

The timing of events were 3 hours for TS, 1 hour break, 6 hours of Config (I stopped TS after 2 hours so ended up with a 2 hour break in between) The good thing about the Cisco 360 labs as far as booking the lab session itself is that the booking is based on a local timezone to the student allowing a good deal of flexibility compared to other rack vendors. The other component that I liked was the automatic grading gave results and feedback in approximately 90 minutes after completion and included a comprehensive marking system and answer key and even a web based system that allows you to compare your configurations against the working reference as well as performing show commands for status and configurations. The Cisco 360 assessment labs are more expensive than other vendors (approximately twice the cost of some) however with the most up to date version of the Troubleshooting scenario, richer and faster results and feedback and flexible booking times do help offset the higher costs.

What was interesting for my particular session was after the assessment lab, a group mentoring session was held which focused only on the TS component. Things that were discussed included NMC's recommended strategy for attempting questions as well as an indepth dive into addressing all of the tickets in the assessment lab we did. This group session was the first time it was run, and while I did find it useful considering it ran for 2.5 hours - I don't think I would attend it against, particularly since it was held at 3am my local time on a Thursday morning (thank goodness for caffeinated beverages or I wouldn't have survived the day at work)

I found the updated TS component in the Cisco 360 Assessment Labs to be very helpful. There are a number of labs available. If you are interested in doing one of these, some of the labs listed on their site are the older TS versions that don't use the IOU environment - so if you want the new labs (highly recommended) take care and select labs that have "TC" in the ordering code. At the time I'm posting the updated labs are

CIERS1-TC-LAB02 (Assessment Lab 2)
CIERS-TC-LAB01 (Assessment Lab 3)
CIERS-TC-LAB02 (Assessment Lab 4)
CIERS2-TC-LAB02 (Assessment Lab 6)
CIERS2-TC-LAB04 (Assessment Lab 8)
CIERS-TC-LAB03 (Assessment Lab 10)
CIERS-TC-LAB04 (Assessment Lab 11)

The lab I took was CIERS-TC-LAB01 (Assessment Lab 3) and this was all paid for out of my own pocket. I'm considering taking another one of these labs before my next attempt, so I think you could say I'm recommending this as a potential tool for your CCIE Lab preparation.

More Troubleshooting Focus

2011-11-08T19:40:00.004+10:00

The blog has been a little quiet lately but I have still been playing with routers in the background. As part of the Micronics Training Bootcamp I attended back in May, some of the Cisco 360 assessment lab material was included, basically it had some Mock Labs that at least for the configuration portion was pretty much on par as what the actual lab itself presented. At the time, the troubleshooting material was very similar as to what you find with other vendors, not bad at all but based on the same physical topology as the configuration components.

Netmasterclass who I believe developed a lot of the Cisco 360 material, have recently reworked the way they provide the troubleshooting environment, and it is now based on Cisco IOU just like the real lab, as this is a virtual environment it is mean to span about 30 devices - I'm uncertain as to whether switches are included in the topology, however I think having to deal with such a large environment will be a good thing. There is quite a rich level of instrumentation and feedback from the Cisco 360 labs, so it should be quite helpful in pinpointing weak points. I have just signed up for a Troubleshooting and mentoring package which includes the lab and a group mentoring session that should help unveil common issues that others may be encountering as well. Due to the timezone differences, it means it will be a 3am session in the middle of the week for me which is a little annoying; however I will be making every attempt to be there regardless (hopefully I wont be too fragile at work the next day)

I have my next lab attempt scheduled for December, hopefully this will assist me in getting over the line.

Another Expensive Lunch

2011-10-18T08:20:00.003+10:00

Yesterday I grappled with the CCIE R&S Version 4.0 lab for the third time and walked away again without a number.

Troubleshooting is again the bane of my existence with configuration being challenging but more of a good exercise. To be quite honest I would have preferred to have given up an hour of configuration time to take an extra half hour for troubleshooting, I think I probably needed an extra 10 minutes to close off another ticket. The score report for the TS section was in alignment with my expectations that I was one ticket away from a pass - which I guess is at least an improvement on each of my previous attempts but still a fail.

I'm very thankful for my wife for her patience and understanding and encouragement not to give up. Her support coupled with the original intentions on why I wanted to pursue this certification in the first place (Like the title of blog says, I do like playing with routers) helps keep the motivation going when the chips are down when otherwise I could throw in the towel. Fortunately I still have some vacation days available I can use for a couple of days preparation before the next attempt however at this rate I think someone may be assigned #31337 before I get my digits :)

EIGRP and Static Routes

2011-10-14T16:05:00.001+10:00

This posting is going to cover an interesting topic - redistribution and specifically redistribution of static routes into EIGRP. Now before you skip the post, we're going to cover how you can make static routes appear as if they are internal to EIGRP.

Here's the initial configs - the topology is R1-R2-R3. Where R1 is not performing any dynamic routing (R2 is it's default gateway) and R2 has an EIGRP adjacency with R3.

hostname R1
interface Loopback0
ip address 10.1.1.0 255.255.255.255
!
interface Loopback1
ip address 10.1.1.1 255.255.255.255
!
interface Loopback2
ip address 10.1.1.2 255.255.255.255
!
interface Loopback3
ip address 10.1.1.3 255.255.255.255
!
interface Serial0/0
ip address 10.1.12.1 255.255.255.0
encapsulation frame-relay
frame-relay map ip 10.1.12.2 102 broadcast
no frame-relay inverse-arp
!
ip route 0.0.0.0 0.0.0.0 10.1.12.2

R2
hostname R2
interface Serial0/0
no ip address
encapsulation frame-relay
no frame-relay inverse-arp
!
interface Serial0/0.21 point-to-point
ip address 10.1.12.2 255.255.255.0
snmp trap link-status
frame-relay interface-dlci 201
!
interface Serial0/0.23 point-to-point
ip address 10.1.23.2 255.255.255.0
snmp trap link-status
frame-relay interface-dlci 203
!
router eigrp 23
redistribute static metric 1 1 1 1 1
network 10.1.23.2 0.0.0.0
no auto-summary
!
ip route 10.1.1.0 255.255.255.255 10.1.12.1
ip route 10.1.1.1 255.255.255.255 10.1.12.1
ip route 10.1.1.2 255.255.255.255 10.1.12.1
ip route 10.1.1.3 255.255.255.255 10.1.12.1

R3
hostname R3
interface Serial0/0
ip address 10.1.23.3 255.255.255.0
encapsulation frame-relay
frame-relay map ip 10.1.23.2 302 broadcast
no frame-relay inverse-arp
!
router eigrp 23
network 10.1.23.3 0.0.0.0
no auto-summary
!

Ok, so nothing special so far, lets have look at what's in the EIGRP topology table:

R2#sh ip eigrp topology
IP-EIGRP Topology Table for AS(23)/ID(10.1.23.2)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status

P 10.1.1.2/32, 1 successors, FD is 2560000256
        via Rstatic (2560000256/0)
P 10.1.1.3/32, 1 successors, FD is 2560000256
        via Rstatic (2560000256/0)
P 10.1.1.0/32, 1 successors, FD is 2560000256
        via Rstatic (2560000256/0)
P 10.1.1.1/32, 1 successors, FD is 2560000256
        via Rstatic (2560000256/0)
P 10.1.23.0/24, 1 successors, FD is 2169856
        via Connected, Serial0/0.23
R2#sh ip eigrp topology 10.1.1.0/32
IP-EIGRP (AS 23): Topology entry for 10.1.1.0/32
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2560000256
Routing Descriptor Blocks:
10.1.12.1, from Rstatic, Send flag is 0x0
      Composite metric is (2560000256/0), Route is External
      Vector metric:
        Minimum bandwidth is 1 Kbit
        Total delay is 10 microseconds
        Reliability is 1/255
        Load is 1/255
        Minimum MTU is 1
        Hop count is 0
      External data:
        Originating router is 10.1.23.2 (this system)
        AS number of route is 0
        External protocol is Static, external metric is 0
        Administrator tag is 0 (0x00000000)

This is all normal, static routes redistributed to into EIGRP are external routes...

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

     10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
D EX    10.1.1.2/32 [170/2560512256] via 10.1.23.2, 00:03:05, Serial0/0
D EX    10.1.1.3/32 [170/2560512256] via 10.1.23.2, 00:03:05, Serial0/0
D EX    10.1.1.0/32 [170/2560512256] via 10.1.23.2, 00:03:05, Serial0/0
D EX    10.1.1.1/32 [170/2560512256] via 10.1.23.2, 00:03:05, Serial0/0
C       10.1.23.0/24 is directly connected, Serial0/0

So as I mentioned earlier we can actually make these static routes appear as internal to EIGRP but to make it happen we need to follow a few rules to make it work:

1) The static routes must use an interface as the next-hop rather than an using the next-hop IP Address:

R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#no ip route 10.1.1.0 255.255.255.255 10.1.12.1
R2(config)#ip route 10.1.1.0 255.255.255.255 s0/0.21
R2(config)#no ip route 10.1.1.1 255.255.255.255 10.1.12.1
R2(config)#ip route 10.1.1.1 255.255.255.255 s0/0.21
R2(config)#no ip route 10.1.1.2 255.255.255.255 10.1.12.1
R2(config)#ip route 10.1.1.2 255.255.255.255 s0/0.21
R2(config)#no ip route 10.1.1.3 255.255.255.255 10.1.12.1
R2(config)#ip route 10.1.1.3 255.255.255.255 s0/0.21

2) Enable EIGRP on the interface that has the static routes (making the interface passive is optional)

R2(config)#router eigrp 23
R2(config-router)#passive-interface Serial0/0.21
R2(config-router)#network 10.1.12.2 0.0.0.0

3) Include the networks of the static routes into EIGRP

R2(config-router)#network 10.1.1.0 0.0.0.3
R2(config-router)#end

Now to see what has changed:

R2#show ip route | b Gateway
Gateway of last resort is not set

     10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
C       10.1.12.0/24 is directly connected, Serial0/0.21
S       10.1.1.2/32 is directly connected, Serial0/0.21
S       10.1.1.3/32 is directly connected, Serial0/0.21
S       10.1.1.0/32 is directly connected, Serial0/0.21
S       10.1.1.1/32 is directly connected, Serial0/0.21
C       10.1.23.0/24 is directly connected, Serial0/0.23

These are still definitely static routes, what about the EIGRP topology?

R2#sh ip eigrp topology 10.1.1.0/32
IP-EIGRP (AS 23): Topology entry for 10.1.1.0/32
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2560000256
Routing Descriptor Blocks:
0.0.0.0, from Rstatic, Send flag is 0x0
      Composite metric is (2560000256/0), Route is Internal
      Vector metric:
        Minimum bandwidth is 1 Kbit
        Total delay is 10 microseconds
        Reliability is 1/255
        Load is 1/255
        Minimum MTU is 1
        Hop count is 0

It is now showing up as an internal route even though it shows it was redistributed from static, what does our EIGRP peer R3 see?

R3#show ip route | b Gateway
Gateway of last resort is not set

     10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
D       10.1.12.0/24 [90/2681856] via 10.1.23.2, 00:02:55, Serial0/0
D       10.1.1.2/32 [90/2560512256] via 10.1.23.2, 00:02:55, Serial0/0
D       10.1.1.3/32 [90/2560512256] via 10.1.23.2, 00:02:55, Serial0/0
D       10.1.1.0/32 [90/2560512256] via 10.1.23.2, 00:02:55, Serial0/0
D       10.1.1.1/32 [90/2560512256] via 10.1.23.2, 00:02:55, Serial0/0
C       10.1.23.0/24 is directly connected, Serial0/0

R3#sh ip eigrp topology 10.1.1.0/32
IP-EIGRP (AS 23): Topology entry for 10.1.1.0/32
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2560512256
Routing Descriptor Blocks:
10.1.23.2 (Serial0/0), from 10.1.23.2, Send flag is 0x0
      Composite metric is (2560512256/2560000256), Route is Internal
      Vector metric:
        Minimum bandwidth is 1 Kbit
        Total delay is 20010 microseconds
        Reliability is 1/255
        Load is 1/255
        Minimum MTU is 1
        Hop count is 1

Yes, those static routes on R2 appear to R3 as if they are internal EIGRP routes. Actually, we can remove the "redistribute static" from the EIGRP process as it is no longer required in this instance.

R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#router eigrp 23
R2(config-router)#no redistribute static
R2(config-router)#end

Strange as it seems, this appears to be a design intent for EIGRP and is documented on Cisco's website about this.

Interdomain Multicast using MSDP

2011-09-27T14:41:00.000+10:00

This post is talking about using MSDP to join multicast domains together.

The topology here is very simple even if it does consist of 6 routers.

R1-R2-R3---------R4-R5-R6

Multicast Domain 1

R1, R2 and R3 use EIGRP as their IGP

AutoRP is used for RP election and R3 will be the RP

Multicast Domain 2

R4, R5 and R6 use OSPF as their IGP
AutoRP is used for RP election and R4 will be the RP

Both Multicast Domains are connected using BGP (R3 AS 3) and (R4 AS 4)
All routers have their loopback0 interfaces and interconnecting interfaces running PIM sparse-mode so we are using "ip pim autorp listener"

Note: AutoRP advertisements are blocked between R3 and R4 on their corresponding interfaces "ip multicast boundary 1" is applied where the 1 refers to an access list which blocks AutoRP rp candidate and mapping agent advertisements but allows all other multicast traffic

The base configurations are shown below

R1
hostname R1
!
no ip domain lookup
ip multicast-routing
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
ip pim sparse-mode
!
interface Serial0/0
description FR Switch
no ip address
encapsulation frame-relay
!
interface Serial0/0.12 point-to-point
description PVC to R2
ip address 10.1.12.1 255.255.255.0
ip pim sparse-mode
frame-relay interface-dlci 102
!
router eigrp 123
network 1.1.1.1 0.0.0.0
network 10.1.12.1 0.0.0.0
no auto-summary
!
ip pim autorp listener

R2
hostname R2
!
no ip domain lookup
ip multicast-routing
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
ip pim sparse-mode
!
interface Loopback23
ip address 23.23.23.2 255.255.255.255
!
interface Serial0/0
description FR Switch
no ip address
encapsulation frame-relay
!
interface Serial0/0.21 point-to-point
description PVC to R1
ip address 10.1.12.2 255.255.255.0
ip pim sparse-mode
frame-relay interface-dlci 201
!
interface Serial0/0.23 point-to-point
description PVC to R3
ip address 10.1.23.2 255.255.255.0
ip pim sparse-mode
frame-relay interface-dlci 203
!
router eigrp 123
network 2.2.2.2 0.0.0.0
network 10.1.12.2 0.0.0.0
network 10.1.23.2 0.0.0.0
no auto-summary
!
ip pim autorp listener

R3
hostname R3
!
no ip domain lookup
ip multicast-routing
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
ip pim sparse-mode
!
interface Loopback34
ip address 34.34.34.3 255.255.255.255
!
interface Serial0/0
description FR Switch
no ip address
encapsulation frame-relay
!
interface Serial0/0.32 point-to-point
description PVC to R2
ip address 10.1.23.3 255.255.255.0
ip pim sparse-mode
frame-relay interface-dlci 302
!
interface Serial0/0.34 point-to-point
description PVC to R4
ip address 10.1.34.3 255.255.255.0
ip pim sparse-mode
frame-relay interface-dlci 304
ip multicast boundary 1
!
router eigrp 123
network 3.3.3.3 0.0.0.0
network 10.1.23.3 0.0.0.0
no auto-summary
!
router bgp 3
no synchronization
bgp log-neighbor-changes
network 34.34.34.3 mask 255.255.255.255
neighbor 10.1.34.4 remote-as 4
no auto-summary
!
ip pim autorp listener
ip pim send-rp-announce Loopback0 scope 3
ip pim send-rp-discovery Loopback0 scope 3
ip msdp peer 34.34.34.4 connect-source Loopback34
!
access-list 1 deny   224.0.1.39
access-list 1 deny   224.0.1.40
access-list 1 permit any

R4
hostname R4
!
no ip domain lookup
ip multicast-routing
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
ip pim sparse-mode
!
interface Loopback34
ip address 34.34.34.4 255.255.255.255
!
interface Serial0/0
description FR Switch
no ip address
encapsulation frame-relay
!
interface Serial0/0.43 point-to-point
description PVC to R3
ip address 10.1.34.4 255.255.255.0
ip pim sparse-mode
frame-relay interface-dlci 403
ip multicast boundary 1
!
interface Serial0/0.45 point-to-point
description PVC to R5
ip address 10.1.45.4 255.255.255.0
ip pim sparse-mode
frame-relay interface-dlci 405
!
router ospf 1
network 4.4.4.4 0.0.0.0 area 0
network 10.1.45.4 0.0.0.0 area 0
!
router bgp 4
no synchronization
bgp log-neighbor-changes
network 34.34.34.4 mask 255.255.255.255
neighbor 10.1.34.3 remote-as 3
no auto-summary
!
ip pim autorp listener
ip pim send-rp-announce Loopback0 scope 3
ip pim send-rp-discovery Loopback0 scope 3
ip msdp peer 34.34.34.3 connect-source Loopback34
!
access-list 1 deny   224.0.1.39
access-list 1 deny   224.0.1.40
access-list 1 permit any

R5
hostname R5
!
no ip domain lookup
ip multicast-routing
!
interface Loopback0
ip address 5.5.5.5 255.255.255.255
ip pim sparse-mode
!
interface Serial0/0
no ip address
encapsulation frame-relay
no frame-relay inverse-arp
!
interface Serial0/0.54 point-to-point
ip address 10.1.45.5 255.255.255.0
ip pim sparse-mode
frame-relay interface-dlci 504
!
interface Serial0/0.56 point-to-point
ip address 10.1.56.5 255.255.255.0
ip pim sparse-mode
frame-relay interface-dlci 506
!
router ospf 1
log-adjacency-changes
network 5.5.5.5 0.0.0.0 area 0
network 10.1.45.5 0.0.0.0 area 0
network 10.1.56.5 0.0.0.0 area 0
!
ip pim autorp listener

R6
hostname R6
!
no ip domain lookup
ip multicast-routing
!
interface Loopback0
ip address 6.6.6.6 255.255.255.255
ip pim sparse-mode
!
interface Serial0/0
no ip address
encapsulation frame-relay
no frame-relay inverse-arp
!
interface Serial0/0.65 point-to-point
ip address 10.1.56.6 255.255.255.0
ip pim sparse-mode
frame-relay interface-dlci 605
!
router ospf 1
log-adjacency-changes
network 6.6.6.6 0.0.0.0 area 0
network 10.1.56.6 0.0.0.0 area 0
!
ip pim autorp listener

Quick verification of RP Mappings

R1/R2/R3 should have R3 as the RP:

R1#sh ip pim rp map
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4
RP 3.3.3.3 (?), v2v1
    Info source: 3.3.3.3 (?), elected via Auto-RP
         Uptime: 00:13:05, expires: 00:02:45

R2#sh ip pim rp map
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4
RP 3.3.3.3 (?), v2v1
    Info source: 3.3.3.3 (?), elected via Auto-RP
         Uptime: 00:13:25, expires: 00:02:23

R3#sh ip pim rp map
PIM Group-to-RP Mappings
This system is an RP (Auto-RP)
This system is an RP-mapping agent (Loopback0)

Group(s) 224.0.0.0/4
RP 3.3.3.3 (?), v2v1
    Info source: 3.3.3.3 (?), elected via Auto-RP
         Uptime: 00:14:41, expires: 00:02:17

R4/R5/R6 will use R4 as their RP:

R4#sh ip pim rp map
PIM Group-to-RP Mappings
This system is an RP (Auto-RP)
This system is an RP-mapping agent (Loopback0)

Group(s) 224.0.0.0/4
RP 4.4.4.4 (?), v2v1
    Info source: 4.4.4.4 (?), elected via Auto-RP
         Uptime: 00:11:28, expires: 00:02:45

R5#sh ip pim rp map
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4
RP 4.4.4.4 (?), v2v1
    Info source: 4.4.4.4 (?), elected via Auto-RP
         Uptime: 00:04:49, expires: 00:02:11

R6#sh ip pim rp map
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4
RP 4.4.4.4 (?), v2v1
    Info source: 4.4.4.4 (?), elected via Auto-RP
         Uptime: 00:05:04, expires: 00:02:55

R3 and R4 each have loopback34 advertised into BGP and use this for MSDP peering. MSDP is used to transmit the knowledge of multicast sources between domains. PIM does not need to be run on these interfaces

R3#sh ip msdp peer
MSDP Peer 34.34.34.4 (?), AS 4
Connection status:
    State: Up, Resets: 0, Connection source: Loopback34 (34.34.34.3)
    Uptime(Downtime): 00:04:40, Messages sent/received: 5/5
    Output messages discarded: 0
    Connection and counters cleared 00:16:10 ago
SA Filtering:
    Input (S,G) filter: none, route-map: none
    Input RP filter: none, route-map: none
    Output (S,G) filter: none, route-map: none
    Output RP filter: none, route-map: none
SA-Requests:
    Input filter: none
Peer ttl threshold: 0
SAs learned from this peer: 0
Input queue size: 0, Output queue size: 0
MD5 signature protection on MSDP TCP connection: not enabled

R4#sh ip msdp peer
MSDP Peer 34.34.34.3 (?), AS 3
Connection status:
    State: Up, Resets: 0, Connection source: Loopback34 (34.34.34.4)
    Uptime(Downtime): 00:04:51, Messages sent/received: 5/5
    Output messages discarded: 0
    Connection and counters cleared 00:12:34 ago
SA Filtering:
    Input (S,G) filter: none, route-map: none
    Input RP filter: none, route-map: none
    Output (S,G) filter: none, route-map: none
    Output RP filter: none, route-map: none
SA-Requests:
    Input filter: none
Peer ttl threshold: 0
SAs learned from this peer: 0
Input queue size: 0, Output queue size: 0
MD5 signature protection on MSDP TCP connection: not enabled

So with everything looking ok, our objective is to verify multicast traffic can traverse the domains by having R1 Loopback0 join multicast group 239.1.1.1 with R6 receive a response when it pings that group

R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#int loopback0
R1(config-if)#ip igmp join-group 239.1.1.1

Lets enable a debug to see if check ping packets arrive (we could use debug ip icmp however that presents less detail):

R1(config-if)#access-list 101 permit icmp any any
R1(config)#do deb ip pack detail 101
IP packet debugging is on (detailed) for access list 101
R1#end
*Mar 1 00:25:49.379: %SYS-5-CONFIG_I: Configured from console by console

R1#sh ip mroute | s 239.1.1.1
(*, 239.1.1.1), 00:05:42/00:02:14, RP 3.3.3.3, flags: SJCL
Incoming interface: Serial0/0.12, RPF nbr 10.1.12.2
Outgoing interface list:
    Loopback0, Forward/Sparse, 00:05:42/00:02:14

R1 has R2 as the RPF neighbor for *,239.1.1.1

R2#sh ip mroute | s 239.1.1.1
(*, 239.1.1.1), 00:04:01/00:03:25, RP 3.3.3.3, flags: S
Incoming interface: Serial0/0.23, RPF nbr 10.1.23.3
Outgoing interface list:
    Serial0/0.21, Forward/Sparse, 00:04:01/00:03:25

R2 has R3 as the RPF neighbor for *,239.1.1.1

R3#sh ip mroute | s 239.1.1.1
(*, 239.1.1.1), 00:04:27/00:02:57, RP 3.3.3.3, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
    Serial0/0.32, Forward/Sparse, 00:04:27/00:02:57

R3 has nothing as the RPF neighbor for *,239.1.1.1

When R6 pings 239.1.1.1 it's RP (R4) will discover it as a new multicast source and advertise it to its MSDP peer (R3)

R3#sh ip msdp sa-cache
MSDP Source-Active Cache - 0 entries
R3#deb ip msdp routes
MSDP Routes debugging is on

R6#ping 239.1.1.1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:
.

Well that was unsuccessful let's see if R3 learnt about our multicast sources:

R3#
*Mar 1 00:04:42.431: MSDP(0): (6.6.6.6/32, 239.1.1.1), accepted
*Mar 1 00:04:42.479: MSDP(0): (10.1.56.6/32, 239.1.1.1), accepted

Yes it did - what did we see on R1?

R1#
*Mar 1 00:04:50.315: IP: s=10.1.12.1 (local), d=6.6.6.6, len 100, unroutable
*Mar 1 00:04:50.319:     ICMP type=0, code=0
*Mar 1 00:04:50.379: IP: s=10.1.12.1 (local), d=10.1.56.6, len 100, unroutable
*Mar 1 00:04:50.379:     ICMP type=0, code=0

We can see that R1 must have recieved the ping because it's attempting to respond, however R6 didn't obtain a reply since R1 doesn't know how to get back to it

R1#sh ip mroute | s 239.1.1.1
(*, 239.1.1.1), 00:07:35/00:02:42, RP 3.3.3.3, flags: SJCL
Incoming interface: Serial0/0.12, RPF nbr 10.1.12.2
Outgoing interface list:
    Loopback0, Forward/Sparse, 00:07:35/00:02:19
(10.1.56.6, 239.1.1.1), 00:00:17/00:02:42, flags: LJ
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
    Loopback0, Forward/Sparse, 00:00:17/00:02:42
(6.6.6.6, 239.1.1.1), 00:00:17/00:02:42, flags: LJ
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
    Loopback0, Forward/Sparse, 00:00:17/00:02:42

We can even see that R1 is trying to build a specific path to get to the multicast sources 10.1.56.6 (R6 S0/0.65) and 6.6.6.6 (R6 Lo0) but is failing the RPF checks

R2#sh ip mroute | s 239.1.1.1
(*, 239.1.1.1), 00:05:39/00:03:11, RP 3.3.3.3, flags: S
Incoming interface: Serial0/0.23, RPF nbr 10.1.23.3
Outgoing interface list:
    Serial0/0.21, Forward/Sparse, 00:05:39/00:02:46

R2 is able to use R3 as its RPF neighbor and pass traffic destined to 239.1.1.1 out to R1

R3#sh ip mroute | s 239.1.1.1
(*, 239.1.1.1), 00:05:41/00:03:02, RP 3.3.3.3, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
    Serial0/0.32, Forward/Sparse, 00:05:41/00:02:41

R3 knows that someone at R2 or further downstream is subscribed to group 239.1.1.1

R3#sh ip msdp sa-cache
MSDP Source-Active Cache - 2 entries
(6.6.6.6, 239.1.1.1), RP 4.4.4.4, BGP/AS 0, 00:02:20/00:05:10, Peer 34.34.34.4
(10.1.56.6, 239.1.1.1), RP 4.4.4.4, BGP/AS 0, 00:02:20/00:05:10, Peer 34.34.34.4

So R3 knows about the sources and that the RP is Lo0 on R4 but doesn't know where the sources came from (BGP/AS 0)

Lets fix this by putting the sources into BGP

R4#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R4(config)#router bgp 4
R4(config-router)#redistribute ospf 1
R4(config-router)#end

Let's see if that's resolved things:

R3#sh ip msdp sa-cache
MSDP Source-Active Cache - 2 entries
(6.6.6.6, 239.1.1.1), RP 4.4.4.4, BGP/AS 4, 00:05:40/00:05:31, Peer 34.34.34.4
(10.1.56.6, 239.1.1.1), RP 4.4.4.4, BGP/AS 4, 00:05:40/00:05:31, Peer 34.34.34.4

R3 has determined these source are via BGP and can establish paths back to the sources

R3#sh ip mroute | s 239.1.1.1
(*, 239.1.1.1), 00:08:03/00:03:17, RP 3.3.3.3, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
    Serial0/0.32, Forward/Sparse, 00:08:03/00:03:17
(6.6.6.6, 239.1.1.1), 00:00:19/00:02:40, flags: M
Incoming interface: Serial0/0.34, RPF nbr 10.1.34.4
Outgoing interface list:
    Serial0/0.32, Forward/Sparse, 00:00:19/00:03:17
(10.1.56.6, 239.1.1.1), 00:00:19/00:02:40, flags: M
Incoming interface: Serial0/0.34, RPF nbr 10.1.34.4
Outgoing interface list:
    Serial0/0.32, Forward/Sparse, 00:00:19/00:03:17

This doesn't work for R1 though as it's not aware of how to get to these sources (RPF nbr 0.0.0.0)

R1#sh ip mroute | s 239.1.1.1
(*, 239.1.1.1), 00:07:35/00:02:42, RP 3.3.3.3, flags: SJCL
Incoming interface: Serial0/0.12, RPF nbr 10.1.12.2
Outgoing interface list:
    Loopback0, Forward/Sparse, 00:07:35/00:02:19
(10.1.56.6, 239.1.1.1), 00:00:17/00:02:42, flags: LJ
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
    Loopback0, Forward/Sparse, 00:00:17/00:02:42
(6.6.6.6, 239.1.1.1), 00:00:17/00:02:42, flags: LJ
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
    Loopback0, Forward/Sparse, 00:00:17/00:02:42

So we need to redistribute those routes into eigrp

R3#conf t
R3(config)#router eigrp 123
R3(config-router)#redistribute bgp 3 metric 1 1 1 1 1
R3(config-router)#end

This should give us a return route for the ping and resolve the RPF for the shortest path to the sources

R1#sh ip route eigrp | i EX

D EX    34.34.34.3 [170/2561024256] via 10.1.12.2, 01:33:57, Serial0/0.12
D EX    34.34.34.4 [170/2561024256] via 10.1.12.2, 01:33:57, Serial0/0.12
D EX    6.6.6.6 [170/2561024256] via 10.1.12.2, 01:33:57, Serial0/0.12
D EX    10.1.56.0 [170/2561024256] via 10.1.12.2, 01:33:57, Serial0/0.12
R1#sh ip mroute | s 239.1.1.1
(*, 239.1.1.1), 00:13:44/stopped, RP 3.3.3.3, flags: SJCL
Incoming interface: Serial0/0.12, RPF nbr 10.1.12.2
Outgoing interface list:
    Loopback0, Forward/Sparse, 00:13:44/00:02:18
(10.1.56.6, 239.1.1.1), 00:00:05/00:02:56, flags: LJT
Incoming interface: Serial0/0.12, RPF nbr 10.1.12.2
Outgoing interface list:
    Loopback0, Forward/Sparse, 00:00:05/00:02:54
(6.6.6.6, 239.1.1.1), 00:00:05/00:02:56, flags: LJT
Incoming interface: Serial0/0.12, RPF nbr 10.1.12.2
Outgoing interface list:
    Loopback0, Forward/Sparse, 00:00:05/00:02:54

So lets give it another shot:

R6#ping 239.1.1.1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:

Reply to request 0 from 10.1.12.1, 32 ms
Reply to request 0 from 10.1.12.1, 32 ms

On R1 we see
R1#
*Mar 1 00:12:47.815: IP: tableid=0, s=10.1.12.1 (local), d=10.1.56.6 (Serial0/0.12), routed via FIB
*Mar 1 00:12:47.815: IP: s=10.1.12.1 (local), d=10.1.56.6 (Serial0/0.12), len 100, sending
*Mar 1 00:12:47.815:     ICMP type=0, code=0
*Mar 1 00:12:47.823: IP: tableid=0, s=10.1.12.1 (local), d=6.6.6.6 (Serial0/0.12), routed via FIB
*Mar 1 00:12:47.827: IP: s=10.1.12.1 (local), d=6.6.6.6 (Serial0/0.12), len 100, sending
*Mar 1 00:12:47.827:     ICMP type=0, code=0

Success!

Backup interfaces (and some EEM)

2011-09-21T13:07:00.000+10:00

This post is discussing the "backup interface" command and gives an example on how it could be used.

The backup interface as its name suggests specifies an interface that is not normally active but is brought online once a primary interface's line protocol goes down. This is a router function, however for switches there is a feature (flexlinks) which is very similar (switchport backup interface) but has more layer 2 features such as keeping the flexlink peer updated with which interface should be associated with learnt MAC addresses, however that is not the focus on this posting.

On the primary interface, we specify which interface shall be our backup interface.

interface PRIMARYINT

backup interface BACKUPINT

Once this occurs, the backup interface is placed in standby mode and the interface is brought down.

When the primary interface fails (failure does not include administratively shutting down the primary interface as IOS believes you are doing this on purpose) the backup interface is brought online on the physical and then line level.   Because of this only one side of a link needs to be set up this way.

In the example below we are going to have 3 Routers.   R1 is connected to R2 via Frame Relay, R2 is connected to R3 via Frame Relay, and R1 is connected to R3 via HDLC. R1 will be configured with a backup interface (the HDLC will be the backup for the Frame Relay) We'll be running a dynamic routing protocol over these links as well.

Here are the configurations:

R1
hostname R1
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface Serial0/0
description FR Switch
no ip address
encapsulation frame-relay
clock rate 2000000
!
interface Serial0/1
description direct to R3
ip address 10.1.13.1 255.255.255.0
clock rate 64000
!
interface Serial0/0.12 point-to-point
backup interface Serial0/1
frame-relay interface-dlci 102 ppp Virtual-Template1
class FREEK
!
interface Virtual-Template1
ip address 10.1.12.1 255.255.255.0
!
router eigrp 100
network 1.1.1.1 0.0.0.0
network 10.1.12.1 0.0.0.0
network 10.1.13.1 0.0.0.0
no auto-summary
!
map-class frame-relay FREEK
frame-relay end-to-end keepalive mode bidirectional

R2
hostname R2
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
interface Serial0/0
description FR Switch
no ip address
encapsulation frame-relay
clock rate 2000000
frame-relay interface-dlci 203 ppp Virtual-Template3
!
interface Serial0/0.21 point-to-point
description PVC to R1
frame-relay interface-dlci 201 ppp Virtual-Template1
class FREEK
!
interface Virtual-Template1
ip address 10.1.12.2 255.255.255.0
!
interface Virtual-Template3
ip address 10.1.23.2 255.255.255.0
!
router eigrp 100
network 2.2.2.2 0.0.0.0
network 10.1.12.2 0.0.0.0
network 10.1.23.2 0.0.0.0
no auto-summary
map-class frame-relay FREEK
frame-relay end-to-end keepalive mode bidirectional

R3
hostname R3
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
interface Serial0/0
no ip address
encapsulation frame-relay
frame-relay interface-dlci 302 ppp Virtual-Template1
!
interface Serial0/1
ip address 10.1.13.3 255.255.255.0
ip summary-address eigrp 100 0.0.0.0 0.0.0.0 255
!
interface Virtual-Template1
ip address 10.1.23.3 255.255.255.0
!
router eigrp 100
network 3.3.3.3 0.0.0.0
network 10.1.13.3 0.0.0.0
network 10.1.23.3 0.0.0.0
no auto-summary

Lets look at some of the interfaces here

R1>sh ip int brief | ex unassigned
Interface                  IP-Address      OK? Method Status                Protocol
Serial0/1                  10.1.13.1       YES NVRAM standby mode          down
Virtual-Access1            10.1.12.1       YES TFTP   up                    up
Virtual-Template1          10.1.12.1       YES NVRAM down                  down
Loopback0                  1.1.1.1         YES NVRAM up                    up

Firstly we can see that Serial0/1 is in a standby mode condition and the line protocol is down. Unfortunately there appears to be no regular show command to determine which interface has S0/1 as its backup interface, so we need to examine the router configuration

R1#sh run | i ^interface|^ backup
interface Loopback0
interface FastEthernet0/0
interface Serial0/0
interface Serial0/0.12 point-to-point
backup interface Serial0/1
interface FastEthernet0/1
interface Serial0/1
interface Virtual-Template1

Here we can see that S0/0.12 has S0/1 as its backup interface

Virtual-Templates appear as down because they aren't actually active interfaces - they have a limited amount of configuration which is used as a baseline config by the Virtual-Access interfaces. Each Virtual-Access represents a dynamic instance of an individual connection.

R1#sh int virtual-template 1
Virtual-Template1 is down, line protocol is down
Hardware is Virtual Template interface
Internet address is 10.1.12.1/24
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
....

Looking at Virtual-Access 1

R1#sh int virtual-access 1
Virtual-Access1 is up, line protocol is up
Hardware is Virtual Access interface
Internet address is 10.1.12.1/24
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
Encapsulation PPP, LCP Open
Open: IPCP
PPPoFR vaccess, cloned from Virtual-Template1
Vaccess status 0x44
Bound to Serial0/0.12 DLCI 102, Cloned from Virtual-Template1, loopback not set
Keepalive set (10 sec)
....

We can see that if a PPP over Frame Relay connection using the PVC on S0/0.12 DLCI 102 and taking the the base IP configuration from the virtual-template. The interface is in an up/up state because the PVC is up and there is a PPP connection established with its peer.

R1#sh frame pvc int s0/0.12 | i PVC STATUS
DLCI = 102, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE (EEK UP), INTERFACE = Serial0/0.12

On S0/0.12 we can see that we are using Frame Relay End-to-End Keep alives. If EEK messages with our peer are non responded to, interface S0/0.12 will have its line protocol go down.

Click here if you would like to know more about using Frame-Relay Keep Alives

R1#sh int s0/01 | i line
Serial0/1 is standby mode, line protocol is down

Since S0/1 is the backup interface for S0/0.12, S0/1 will then be brought out of standby mode and the physical interface will go active. Once S0/0.12 responds to EEK messages again, S0/1 will re-enter standby state and the physical interface will go down.

R2#sh ip int bri | ex unassigned
Interface                  IP-Address      OK? Method Status                Protocol
Virtual-Access1            10.1.23.2       YES TFTP   up                    up
Virtual-Template1          10.1.12.2       YES NVRAM down                  down
Virtual-Access2            10.1.12.2       YES TFTP   up                    up
Virtual-Template3          10.1.23.2       YES NVRAM down                  down
Loopback0                  2.2.2.2         YES NVRAM up                    up

R2 has PVCs with R1 and R3. To ensure that FR EEK operates, as expected, a subinterface is created in order for it too to go down if EEK messages are not responded to.

R3#sh ip int bri | ex unassigned
Interface                  IP-Address      OK? Method Status                Protocol
Serial0/1                  10.1.13.3       YES NVRAM up                    down
Virtual-Access1            10.1.23.3       YES TFTP   up                    up
Virtual-Template1          10.1.23.3       YES NVRAM down                  down
Loopback0                  3.3.3.3         YES NVRAM up                    up

R3 has a PVC to R2, and a low speed link to R1. R3 will advertise a default route to R1 using a summarization. As we don't want R3 to have a default route to null0, we shall set the admin distance of the summary to 255 (which means it wont get installed in the local routing table) as a general rule if we are doing route summarization we actually desire the route to null0 as it is used to sink traffic rate than potentially have traffic bouncing around the network until the TTL expires.

R3#sh run int s0/1
Building configuration...

Current configuration : 133 bytes
!
interface Serial0/1
ip address 10.1.13.3 255.255.255.0
ip summary-address eigrp 100 0.0.0.0 0.0.0.0 255

As this interface is normally down (brought up by R1 to come up only when its PVC to R2 is down), R1 will not distribute the default to R2

We've explained what should occur, lets test things - first lets start in the normal operating state:

R1
R1#sh ip int brief | ex unassigned
Interface                  IP-Address      OK? Method Status                Protocol
Serial0/1                  10.1.13.1       YES NVRAM standby mode          down
Virtual-Access1            10.1.12.1       YES TFTP   up                    up
Virtual-Template1          10.1.12.1       YES NVRAM down                  down
Loopback0                  1.1.1.1         YES NVRAM up                    up

R1#sh ip route eigrp
     2.0.0.0/32 is subnetted, 1 subnets
D       2.2.2.2 [90/2713600] via 10.1.12.2, 00:28:38, Virtual-Access1
     3.0.0.0/32 is subnetted, 1 subnets
D       3.3.3.3 [90/5273600] via 10.1.12.2, 00:28:38, Virtual-Access1
     10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
D       10.1.23.0/24 [90/5145600] via 10.1.12.2, 00:28:38, Virtual-Access1
D       10.1.23.3/32 [90/5145600] via 10.1.12.2, 00:28:38, Virtual-Access1

R1#trace 2.2.2.2 so lo0

Type escape sequence to abort.
Tracing the route to 2.2.2.2

1 10.1.12.2 8 msec * 12 msec

R1#trace 3.3.3.3 so lo0

Type escape sequence to abort.
Tracing the route to 3.3.3.3

1 10.1.12.2 0 msec 4 msec 0 msec
2 10.1.23.3 8 msec * 16 msec

R2
R2#sh ip int bri | exc unassigned
Interface                  IP-Address      OK? Method Status                Protocol
Virtual-Access1            10.1.23.2       YES TFTP   up                    up
Virtual-Template1          10.1.12.2       YES NVRAM down                  down
Virtual-Access2            10.1.12.2       YES TFTP   up                    up
Virtual-Template3          10.1.23.2       YES NVRAM down                  down
Loopback0                  2.2.2.2         YES NVRAM up                    up
R2#sh ip route eigrp
     1.0.0.0/32 is subnetted, 1 subnets
D       1.1.1.1 [90/2713600] via 10.1.12.1, 00:29:32, Virtual-Access2
     3.0.0.0/32 is subnetted, 1 subnets
D       3.3.3.3 [90/2713600] via 10.1.23.3, 01:10:30, Virtual-Access1
R2#trace 1.1.1.1 so lo0

Type escape sequence to abort.
Tracing the route to 1.1.1.1

1 10.1.12.1 4 msec * 16 msec
R2#trace 3.3.3.3 so lo0

Type escape sequence to abort.
Tracing the route to 3.3.3.3

1 10.1.23.3 0 msec * 12 msec

R3
R3#sh ip int bri | exc unassigned
Interface                  IP-Address      OK? Method Status                Protocol
Serial0/1                  10.1.13.3       YES NVRAM up                    down
Virtual-Access1            10.1.23.3       YES TFTP   up                    up
Virtual-Template1          10.1.23.3       YES NVRAM down                  down
Loopback0                  3.3.3.3         YES NVRAM up                    up
R3#sh ip route eigrp
     1.0.0.0/32 is subnetted, 1 subnets
D       1.1.1.1 [90/5273600] via 10.1.23.2, 00:25:01, Virtual-Access1
     2.0.0.0/32 is subnetted, 1 subnets
D       2.2.2.2 [90/2713600] via 10.1.23.2, 00:30:40, Virtual-Access1
     10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
D       10.1.12.1/32 [90/5145600] via 10.1.23.2, 00:30:43, Virtual-Access1
D       10.1.12.0/24 [90/5145600] via 10.1.23.2, 00:25:02, Virtual-Access1
R3#trace 1.1.1.1 so lo0

Type escape sequence to abort.
Tracing the route to 1.1.1.1

1 10.1.23.2 4 msec 0 msec 4 msec
2 10.1.12.1 4 msec * 16 msec
R3#trace 2.2.2.2 so lo0

Type escape sequence to abort.
Tracing the route to 2.2.2.2

1 10.1.23.2 0 msec * 24 msec

So the Baseline is ok, we have reachability only using the Frame Relay links, now Lets cause the PVC between R1 and R2 to fail. The routers are synched to the same time source so the timestamps will have meaning across routers:

R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#int s0/0.21
R2(config-subif)#shut
R2(config-subif)#end
Mar 1 00:56:16.133: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.1.12.1 (Virtual-Access2) is down: holding time expired
Mar 1 00:56:25.593: %FR_EEK-5-FAILED: Interface Serial0/0.21 - DLCI 201
Mar 1 00:56:25.609: %LINK-3-UPDOWN: Interface Virtual-Access2, changed state to down
Mar 1 00:56:26.605: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access2, changed state to down

EIGRP detects the failure before FREEK does and the Virtual-Access interface is brought down

On R1 we see:
Mar 1 00:56:15.779: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.1.12.2 (Virtual-Access1) is down: holding time expired
Mar 1 00:56:25.823: %FR_EEK-5-FAILED: Interface Serial0/0.12 - DLCI 102
Mar 1 00:56:25.835: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to down
Mar 1 00:56:26.835: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to down
Mar 1 00:56:28.275: %LINK-3-UPDOWN: Interface Serial0/1, changed state to up
Mar 1 00:56:29.283: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/1, changed state to up
Mar 1 00:56:41.811: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.1.13.3 (Serial0/1) is up: new adjacency

EIGRP detects the failure before FREEK does and the Virtual-Access interface is brought down, and the HDLC interface (S0/1) is brought up and an EIGRP adjacency is formed

On R3 we see:
Mar 1 00:56:39.061: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/1, changed state to up
Mar 1 00:56:41.772: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.1.13.1 (Serial0/1) is up: new adjacency

So we can definitely know that when FREEK failed R1 brought int S0/1 up

R1#sh ip int bri | exc unas
Interface                  IP-Address      OK? Method Status                Protocol
Serial0/1                  10.1.13.1       YES NVRAM up                    up
Virtual-Access1            10.1.12.1       YES TFTP   down                  down
Virtual-Template1          10.1.12.1       YES NVRAM down                  down
Loopback0                  1.1.1.1         YES NVRAM up                    up
R1#sh ip route eigrp
D*   0.0.0.0/0 [90/2297856] via 10.1.13.3, 00:02:49, Serial0/1

We're getting the default from R3, and all traffic is traversing the HDLC link via R3

R1#trace 2.2.2.2 so lo0

Type escape sequence to abort.
Tracing the route to 2.2.2.2

1 10.1.13.3 4 msec 4 msec 0 msec
2 10.1.23.2 4 msec * 20 msec
R1#trace 3.3.3.3 so lo0

Type escape sequence to abort.
Tracing the route to 3.3.3.3

1 10.1.13.3 0 msec * 24 msec

Lets check R2

R2#sh ip int bri | exc unas
Interface                  IP-Address      OK? Method Status                Protocol
Virtual-Access1            10.1.23.2       YES TFTP   up                    up
Virtual-Template1          10.1.12.2       YES NVRAM down                  down
Virtual-Access2            10.1.12.2       YES TFTP   down                  down
Virtual-Template3          10.1.23.2       YES NVRAM down                  down
Loopback0                  2.2.2.2         YES NVRAM up                    up
R2#sh ip route eigrp
     1.0.0.0/32 is subnetted, 1 subnets
D       1.1.1.1 [90/4857856] via 10.1.23.3, 00:04:47, Virtual-Access1
     3.0.0.0/32 is subnetted, 1 subnets
D       3.3.3.3 [90/2713600] via 10.1.23.3, 01:23:38, Virtual-Access1
     10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
D       10.1.13.0/24 [90/4729856] via 10.1.23.3, 00:04:50, Virtual-Access1

R2#trace 1.1.1.1 so lo0

Type escape sequence to abort.
Tracing the route to 1.1.1.1

1 10.1.23.3 4 msec 0 msec 4 msec
2 10.1.13.1 4 msec * 4 msec
R2#trace 3.3.3.3 so lo0

Type escape sequence to abort.
Tracing the route to 3.3.3.3

1 10.1.23.3 4 msec * 4 msec

Yes, understandably with the PVC to R1 down, R2 can only go through R3, and speaking of R3:

R3#sh ip int brie | exc unas
Interface                  IP-Address      OK? Method Status                Protocol
Serial0/1                  10.1.13.3       YES NVRAM up                    up
Virtual-Access1            10.1.23.3       YES TFTP   up                    up
Virtual-Template1          10.1.23.3       YES NVRAM down                  down
Loopback0                  3.3.3.3         YES NVRAM up                    up
R3#sh ip route eigrp
     1.0.0.0/32 is subnetted, 1 subnets
D       1.1.1.1 [90/2297856] via 10.1.13.1, 00:06:20, Serial0/1
     2.0.0.0/32 is subnetted, 1 subnets
D       2.2.2.2 [90/2713600] via 10.1.23.2, 00:44:12, Virtual-Access1
R3#trace 1.1.1.1 so lo0

Type escape sequence to abort.
Tracing the route to 1.1.1.1

1 10.1.13.1 0 msec * 12 msec
R3#trace 2.2.2.2 so lo0

Type escape sequence to abort.
Tracing the route to 2.2.2.2

1 10.1.23.2 0 msec * 24 msec

All good. Lets verify that things return to normal once the PVC between R1 and R2 is restored

R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#int s0/0.21
R2(config-subif)#no shut
R2(config-subif)#end

Looking at R1 we see:
Mar 1 01:09:37.623: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up
Mar 1 01:09:38.319: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.1.13.3 (Serial0/1) is down: interface down
Mar 1 01:09:38.623: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to up
Mar 1 01:09:40.279: %LINK-5-CHANGED: Interface Serial0/1, changed state to standby mode
Mar 1 01:09:40.931: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.1.12.2 (Virtual-Access1) is up: new adjacency
Mar 1 01:09:41.279: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/1, changed state to down

R2 shows:
Mar 1 01:09:37.595: %LINK-3-UPDOWN: Interface Virtual-Access2, changed state to up
Mar 1 01:09:38.615: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access2, changed state to up
Mar 1 01:09:40.899: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.1.12.1 (Virtual-Access2) is up: new adjacency

And R3:
Mar 1 01:09:52.748: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.1.13.1 (Serial0/1) is down: holding time expired
Mar 1 01:10:09.095: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/1, changed state to down

We can see that once the PPPoFR Link between R1 and R2 comes up quickly and that R1 S0/1 is put into standby mode and the direct link between R1 and R3 is brought back down

R1#sh ip route eigrp
     2.0.0.0/32 is subnetted, 1 subnets
D       2.2.2.2 [90/2713600] via 10.1.12.2, 00:04:10, Virtual-Access1
     3.0.0.0/32 is subnetted, 1 subnets
D       3.3.3.3 [90/5273600] via 10.1.12.2, 00:04:10, Virtual-Access1
     10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
D       10.1.23.0/24 [90/5145600] via 10.1.12.2, 00:04:10, Virtual-Access1
D       10.1.23.3/32 [90/5145600] via 10.1.12.2, 00:04:10, Virtual-Access1
R1#ping 2.2.2.2 so lo0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
R1#ping 3.3.3.3 so lo0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

R2#sh ip route eigrp
     1.0.0.0/32 is subnetted, 1 subnets
D       1.1.1.1 [90/2713600] via 10.1.12.1, 00:04:53, Virtual-Access2
     3.0.0.0/32 is subnetted, 1 subnets
D       3.3.3.3 [90/2713600] via 10.1.23.3, 01:36:43, Virtual-Access1

R2#ping 3.3.3.3 so lo0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 2.2.2.2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

R3#sh ip route eigrp
     1.0.0.0/32 is subnetted, 1 subnets
D       1.1.1.1 [90/5273600] via 10.1.23.2, 00:05:33, Virtual-Access1
     2.0.0.0/32 is subnetted, 1 subnets
D       2.2.2.2 [90/2713600] via 10.1.23.2, 00:56:37, Virtual-Access1
     10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
D       10.1.12.1/32 [90/5145600] via 10.1.23.2, 00:05:48, Virtual-Access1
D       10.1.12.0/24 [90/5145600] via 10.1.23.2, 00:05:33, Virtual-Access1

So that's backup interfaces... Of course, there are other ways to implement similar concepts.... EEM for example:

On R1 we insert the config below - note: we need to initially shutdown S0/1 because we don't want both interfaces to be active at the same time, and normally subinterface status is not logged, since we want match upon S0/0.12 going up or down, we will turn that on

interface Serial0/1
shutdown
!
interface Serial0/0.12
no backup interface Serial0/1
logging event subif-link-status
!
event manager applet FR-Down
event syslog pattern "%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0.12, changed state to down"
action 1.0 cli command "enable"
action 2.0 cli command "conf t"
action 3.0 cli command "int s0/1"
action 4.0 cli command "no shut"
event manager applet FR-Up
event syslog pattern "%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0.12, changed state to up"
action 1.0 cli command "enable"
action 2.0 cli command "conf t"
action 3.0 cli command "int s0/1"
action 4.0 cli command "shut"
!

Now let's test it:

R1#sh ip int bri | exc unas
Interface                  IP-Address      OK? Method Status                Protocol
Serial0/1                  10.1.13.1       YES NVRAM administratively down down
Virtual-Access1            10.1.12.1       YES TFTP   up                    up
Virtual-Template1          10.1.12.1       YES NVRAM down                  down
Loopback0                  1.1.1.1         YES NVRAM up                    up

R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#int s0/0.21
R2(config-subif)#shut
R2(config-subif)#end

On R1 we see:
Mar 1 04:51:58.346: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.1.12.2 (Virtual-Access1) is down: holding time expired
Mar 1 04:52:13.382: %FR_EEK-5-FAILED: Interface Serial0/0.12 - DLCI 102
Mar 1 04:52:13.390: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0.12, changed state to down
Mar 1 04:52:13.426: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to down
Mar 1 04:52:13.790: %SYS-5-CONFIG_I: Configured from console by vty0
Mar 1 04:52:14.426: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to down
Mar 1 04:52:15.730: %LINK-3-UPDOWN: Interface Serial0/1, changed state to up
Mar 1 04:52:16.738: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/1, changed state to up
Mar 1 04:52:21.338: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.1.13.3 (Serial0/1) is up: new adjacency

It's a similar turn of events as to what happens with the backup interface, however we see that a configuration change was made (this is where S0/1 has the no shut applied)

R1#sh ip int bri | ex unas
Interface                  IP-Address      OK? Method Status                Protocol
Serial0/1                  10.1.13.1       YES NVRAM up                    up
Virtual-Access1            10.1.12.1       YES TFTP   down                  down
Virtual-Template1          10.1.12.1       YES NVRAM down                  down
Loopback0                  1.1.1.1         YES NVRAM up                    up

R1#sh ip route eigrp
D*   0.0.0.0/0 [90/2297856] via 10.1.13.3, 00:00:57, Serial0/1
So far, so good - lets restore the PVC

R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#int s0/0.21
R2(config-subif)#no shut
R2(config-subif)#end

On R1 we see:
Mar 1 04:54:07.366: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0.12, changed state to up
Mar 1 04:54:07.410: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up
Mar 1 04:54:07.654: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.1.13.3 (Serial0/1) is down: interface down
Mar 1 04:54:07.694: %SYS-5-CONFIG_I: Configured from console by vty0
Mar 1 04:54:07.926: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.1.12.2 (Virtual-Access1) is up: new adjacency
Mar 1 04:54:08.418: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to up
Mar 1 04:54:09.634: %LINK-5-CHANGED: Interface Serial0/1, changed state to administratively down
Mar 1 04:54:10.634: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/1, changed state to down

R1#sh ip route eigrp
     2.0.0.0/32 is subnetted, 1 subnets
D       2.2.2.2 [90/2713600] via 10.1.12.2, 00:00:56, Virtual-Access1
     3.0.0.0/32 is subnetted, 1 subnets
D       3.3.3.3 [90/5273600] via 10.1.12.2, 00:00:56, Virtual-Access1
     10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
D       10.1.23.0/24 [90/5145600] via 10.1.12.2, 00:00:56, Virtual-Access1
D       10.1.23.3/32 [90/5145600] via 10.1.12.2, 00:00:56, Virtual-Access1

Advantages to using the backup interface command:
1) In a show ip interface brief, you can see that the backup interface is in standby state (in the EEM config perhaps in the description you can put something there but thats it)
2) Less configuration, less chance of error
3) No modifications to the configuration - the EEM config keeps changing the config to shut/no shut interfaces

Advantage to using EEM:
1) The only thing EEM offers over the built in functionality is potentially more flexibility - with EEM could email you to let you know the PVC is down, clear counters or other things - this may be handy if you're not sitting in front of your syslog server

Strike 2

2011-09-14T07:32:00.000+10:00

Just a few days ago I gave the CCIE R&S Version 4.0 Lab Exam a second shot. Unfortunately for me I am not bragging about having a CCIE number allocated to me yet.

I certainly felt pretty confident and prepared when I sat the exam. Especially in the troubleshooting I felt more relaxed and was going through the trouble tickets much more methodically and quickly than last time. Although there was one ticket in particular I couldn't resolve, at the close of that session I actually thought I had enough points to have passed TS.

The config section was pretty good as well, I found it fairly straight forward, there were some things I hadn't used in particular combinations before but they came together pretty well and in the end I recieved a pass in Config.

As part of the preparation efforts for attempt #2 I used the Micronics Training troubleshooting workbook, I definitely found that it contributed to my speed and methodology in identifying and resolving issues. I also used a mocklab from Internet Expert which also indicated that my troubleshooting techniques were well under way.

It's a little disheartening to have not passed, particularly since I felt I was as prepared as I needed to be, however this was not my last shot at the lab. I have invested a lot of time and money on this and I know for a fact that this exam is passable for me to give up now (realistically if I keep hitting a wall I may need to re-evaluate this decision). In between lab attempts I have seen improvements in myself and they have been realised in the score reports so there is a fair chance that it will be it.

I tell myself that if it was so easy, everyone would have the certification and there would be no desire to achieve, nor any prestige associated with the certification. The study up to now has pushed me to cover areas of networking that I wouldn't necessarily need to know in my day to day job and has caused me to understand protocols in greater depth and opening my eyes up to potentially more possibilities in future projects, so I am seeing value in the study itself even without the certification. At the moment passing the exam is more of getting an affirmation that I have that capability (and can pass a synthetic exam)

When will I give attempt #3 a go? Probably sooner than later, it would be particularly good to pick up my number by years end.

MFR (Multilink Frame Relay FRF.16) Revisited

2011-09-06T08:50:00.000+10:00

Some time ago I blogged briefly about MFR but only had it working with back-to-back routers because at the time, I couldn't work out how to get it to work through a Frame-Relay Switch. After catching this statement on CCO, I finally understood that the FR Switch actually had to be MFR enabled as well.

Because of this, you can do some interesting things.

This topology will have 3 devices (R1, R2 and a FrameSwitch)

R1==MFR==FRSW--FR--R2

My crude diagram above is meant to indicate that R1 has two physical links to FRSW and is using MFR, while R2 has a single physical link to FRSW using regular frame-relay.

Why might you do this? R1 could be a hub site serving multiple spokes like R2, and the Service Provider for whatever reason cant deliver big pipes to the hub site. As opposed to having R1 and FRSW having just two links with the spokes distributed across the interfaces, besides any bandwidth gains, MFR also enables some resiliency (losing a single physical link can still keep all spokes connected at diminished capacity)

These are the configurations:

R1
hostname R1
!
interface MFR1
no ip address
frame-relay multilink bid R1-MFR1
no frame-relay inverse-arp
!
interface MFR1.12 point-to-point
ip address 10.1.12.1 255.255.255.0
snmp trap link-status
frame-relay interface-dlci 102
!
interface Serial0/0
description FRSW S0/0
no ip address
encapsulation frame-relay MFR1
no arp frame-relay
frame-relay multilink lid R1-S0/0
!
interface Serial0/1
description FRSW S0/1
no ip address
encapsulation frame-relay MFR1
no arp frame-relay
frame-relay multilink lid R1-S0/1

FRSW
hostname FRSW
frame-relay switching
!
interface MFR1
no ip address
frame-relay multilink bid FRSW-MFR1
frame-relay intf-type dce
frame-relay route 102 interface Serial1/0 201
!
interface Serial0/0
description R1 S0/0
no ip address
encapsulation frame-relay MFR1
clock rate 2000000
no arp frame-relay
frame-relay multilink lid FRSW-S0/0
!
interface Serial0/1
description R1 S0/1
no ip address
encapsulation frame-relay MFR1
clock rate 2000000
no arp frame-relay
frame-relay multilink lid FRSW-S0/1
!
interface Serial1/0
description R2 S0/0
no ip address
encapsulation frame-relay
serial restart-delay 0
frame-relay intf-type dce
frame-relay route 201 interface MFR1 102

R2
hostname R2
!
interface Serial0/0
description FRSW S1/0
no ip address
encapsulation frame-relay
no fair-queue
no frame-relay inverse-arp
!
interface Serial0/0.21 point-to-point
ip address 10.1.12.2 255.255.255.0
frame-relay interface-dlci 201
!

Within the MFR configuration we have added some optional statements which identify the MFR bundle:

interface MFR
frame-relay multilink bid MFRBundleIDString

And the links which make up the bundle:

interface Serial
frame-relay multilink lid LinkIDString

This kind of thing can help with Layer 2 troubleshooting if you have a lot of peers.

R1#sh frame multi de | i BID|Peer|LID
 BID = R1-MFR1
 No. of bundle links = 2, Peer's bundle-id = FRSW-MFR1
  Serial0/1, HW state = up, link state = Up, LID = R1-S0/1
    Peer LID = FRSW-S0/1, RTT = 20 ms
  Serial0/0, HW state = up, link state = Up, LID = R1-S0/0
    Peer LID = FRSW-S0/0, RTT = 24 ms

FRSW#sh frame multi de | i BID|Peer|LID
BID = FRSW-MFR1
No. of bundle links = 2, Peer's bundle-id = R1-MFR1
Serial0/1, HW state = up, link state = Up, LID = FRSW-S0/1
    Peer LID = R1-S0/1, RTT = 0 ms
Serial0/0, HW state = up, link state = Up, LID = FRSW-S0/0
    Peer LID = R1-S0/0, RTT = 0 ms

So from above, we can see that that the bundle is up with both links and we appear to be connected to the right peer interfaces.

So lets see the PVC status on the Frame Switch:

FRSW#sh frame pvc

PVC Statistics for interface Serial1/0 (Frame Relay DCE)

              Active     Inactive      Deleted       Static
Local          0            0            0            0
Switched       1            0            0            0
Unused         0            0            0            0

DLCI = 201, DLCI USAGE = SWITCHED, PVC STATUS = ACTIVE, INTERFACE = Serial1/0

input pkts 33            output pkts 29           in bytes 7428
out bytes 4708           dropped pkts 12          in pkts dropped 12
out pkts dropped 0                out bytes dropped 0
in FECN pkts 0           in BECN pkts 0           out FECN pkts 0
out BECN pkts 0          in DE pkts 0             out DE pkts 0
out bcast pkts 0         out bcast bytes 0
30 second input rate 0 bits/sec, 0 packets/sec
30 second output rate 0 bits/sec, 0 packets/sec
switched pkts 24
Detailed packet drop counters:
no out intf 0            out intf down 0          no out PVC 0
in PVC down 0            out PVC down 12          pkt too big 0
shaping Q full 0         pkt above DE 0           policing drop 0
pvc create time 00:10:17, last time pvc status changed 00:06:07

PVC Statistics for interface MFR1 (Frame Relay DCE)

              Active     Inactive      Deleted       Static
Local          0            0            0            0
Switched       1            0            0            0
Unused         0            0            0            0

DLCI = 102, DLCI USAGE = SWITCHED, PVC STATUS = ACTIVE, INTERFACE = MFR1

input pkts 30            output pkts 24           in bytes 5029
out bytes 4494           dropped pkts 0           in pkts dropped 0
out pkts dropped 0                out bytes dropped 0
in FECN pkts 0           in BECN pkts 0           out FECN pkts 0
out BECN pkts 0          in DE pkts 0             out DE pkts 0
out bcast pkts 0         out bcast bytes 0
30 second input rate 0 bits/sec, 0 packets/sec
30 second output rate 0 bits/sec, 0 packets/sec
switched pkts 30
Detailed packet drop counters:
no out intf 0            out intf down 0          no out PVC 0
in PVC down 0            out PVC down 0           pkt too big 0
shaping Q full 0         pkt above DE 0           policing drop 0
pvc create time 00:06:14, last time pvc status changed 00:05:54

FRSW#sh frame route
Input Intf      Input Dlci      Output Intf     Output Dlci     Status
Serial1/0       201             MFR1            102             active
MFR1            102             Serial1/0       201             active

Looks good here, lets see what R1 and R2 have to say

R1#sh frame pvc

PVC Statistics for interface MFR1 (Frame Relay DTE)

              Active     Inactive      Deleted       Static
Local          1            0            0            0
Switched       0            0            0            0
Unused         0            0            0            0

DLCI = 102, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = MFR1.12

input pkts 12            output pkts 19           in bytes 2802
out bytes 3929           dropped pkts 0           in pkts dropped 0
out pkts dropped 0                out bytes dropped 0
in FECN pkts 0           in BECN pkts 0           out FECN pkts 0
out BECN pkts 0          in DE pkts 0             out DE pkts 0
out bcast pkts 9         out bcast bytes 2889
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
pvc create time 00:08:34, last time pvc status changed 00:04:20
R1#sh frame map
MFR1.12 (up): point-to-point dlci, dlci 102(0x66,0x1860), broadcast
          status defined, active

R2#sh frame pvc

PVC Statistics for interface Serial0/0 (Frame Relay DTE)

              Active     Inactive      Deleted       Static
Local          1            0            0            0
Switched       0            0            0            0
Unused         0            0            0            0

DLCI = 201, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.21

input pkts 18            output pkts 22           in bytes 3608
out bytes 6062           dropped pkts 0           in pkts dropped 0
out pkts dropped 0                out bytes dropped 0
in FECN pkts 0           in BECN pkts 0           out FECN pkts 0
out BECN pkts 0          in DE pkts 0             out DE pkts 0
out bcast pkts 17        out bcast bytes 5542
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
pvc create time 00:09:40, last time pvc status changed 00:05:30
R2#sh frame map
Serial0/0.21 (up): point-to-point dlci, dlci 201(0xC9,0x3090), broadcast
          status defined, active

And lets verify layer 3 connectivity:

R2#ping 10.1.12.2

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

There are more things you can do with MFR which include the specifying the method of using the bundles (variable bandwidth class support). By default, IOS will use bandwidth class a (the MFR will stay active with downed link members as long as a single link is up), other options include class b (all links must be active to keep the MFR interface up) or class c (a minimum threshold of links to keep the MFR interface up)

interface MFR
frame-relay multilink bandwidth-class BandwidthClass LinkThresholdForClassC

Load Balancing:
When the MFR interface is not using FIFO queuing, the router will simly pick the interface with the empty or shortest queue to send traffic to. If FIFO is being used then there is a default output-threshold of 300 bytes for each link, once this is exceeded, the next interface is selected. It is possible to modify this value to a different level (this is not FRF.12 frame-relay fragmentation)

interface MFR
frame-relay multilink output-threshold Threshold

Catalyst Switch QoS

2011-08-27T16:38:00.000+10:00

Layer 2 Qos is part of the R&S Blueprint and the pieces supporting how SRR queuing actually works can get quite confusing even though there is a method to the madness.

Vik Malhi has distilled this information into 3 blog posts which cover classification and marking, ingress queuing and scheduling and closing off with egress queueing, dropping and scheduling which can be found here. Although this is primarily on the Catalyst 3750 platform, it shares many of the concepts that the Catalyst 3560 has and is configured and tested in the same manner.

These blog posts and the explanation from Narbik which he gave at his bootcamp turns a complex topic into something a bit more bearable..