Month: February 2013

Creating a dynamips SP topology with real switch breakout

The vast majority of the SP exam is routing. Very little switching is involved. I wanted to create a new INE SPv3 topology, but replace the IOS-XR devices with Juniper M routers. I didn’t want to have to connect the IOS routers to each other via a real switch, rather a virtual one. I did however need a ‘breakout’ to a real switch so I could connect this to my M10 router. This is also all running on top of a vmware server.

I created a new vswitch on an unused physical NIC on the server. You need to enable promiscuous mode on this vswitch. I then created two port groups. One tagged with vlan 501 and the second with vlan 502. Promiscuous mode on both.

I then created a VM. It had three virtual NICs. One was the main one where I would be logging on. The other two were each connected to one of the created port groups.

I connected the physical server port to a 3750 and enabled dot1q trunking. I also just allowed vlans 501 and 502.

Once dynamips was installed I created the following .net file:

autostart = False
[10.0.0.1:7200]
    workingdir = /home/darreno/dynamips/working/multisitel3vpn
[[7200]]
        image = /home/darreno/dynamips/ios/7200/c7200-advipservicesk9-mz.122-33.SRE7.bin
        ram = 512
        idlepc = 0x6278f1a4
        ghostios = True
[[ROUTER R1]]
        model = 7200
        console = 2001
        f0/0 = s1 1
[[ROUTER R2]]
        model = 7200
        console = 2002
        f0/0 = s1 2
	f1/0 = s1 3
[[ROUTER R3]]
        model = 7200
        console = 2003
        f0/0 = s1 4
[[ROUTER R4]]
        model = 7200
        console = 2004
        f0/0 = s1 5
	f1/0 = s1 6
[[ROUTER R5]]
        model = 7200
        console = 2005
        f0/0 = s1 7
	f1/0 = s1 8
[[ROUTER R6]]
        model = 7200
        console = 2006
	f0/0 = s1 9
[[ROUTER R7]]
        model = 7200
        console = 2007
	fa0/0 = s1 10
[[ROUTER R8]]
        model = 7200
        console = 2008
	fa0/0 = s1 11
		
[[ETHSW s1]]
	1 = dot1q 1
	2 = dot1q 1
	3 = dot1q 1
	4 = dot1q 1
	5 = dot1q 1
	6 = dot1q 1
	7 = dot1q 1
	8 = dot1q 1
	9 = dot1q 1
	10 = dot1q 1
	11 = dot1q 1
	12 = access 501 NIO_linux_eth:eth1
	13 = access 502 NIO_linux_eth:eth2

Each router’s port is connected to a virtual switch. dot1q is running so I can run subinterfaces and not have to worry about ‘rewiring’ this switch. Ports 12 and 13 are then connected to the virtual NICs our to the 3750. From there I can use vlans to connect my emulated devices to the Junipers.

Does this all work?

darreno:JR1> show configuration interfaces ae1.501
vlan-id 501;
family inet {
    address 10.0.0.11/24;
}

darreno:JR1> ping 10.0.0.3 count 5 rapid
PING 10.0.0.3 (10.0.0.3): 56 data bytes
!!!!!
--- 10.0.0.3 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 3.132/3.878/4.754/0.529 ms
R3#sh run int fa0/0.501
Building configuration...

Current configuration : 97 bytes
!
interface FastEthernet0/0.501
 encapsulation dot1Q 501
 ip address 10.0.0.3 255.255.255.0
end

R3#ping 10.0.0.11

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

No problems there.

Basic MPLS L3VPN Interop – IOS, Junos, Brocade Netiron – Part 2 of 2

This is an ongoing post. Part 1 is over here:http://mellowd.co.uk/ccie/?p=3423

Label values

Other than the config I’ve done before, all the other config is left to defaults. Let’s have a look at label allocations. I’ve run wireshark and then captures a ping to each CE. The bottom label is the VPN given by the last hop router.
IOS:

Netiron:

Junos:

IOS assigns labels from 10 upwards. Junos assigns from 300000 downwards. Netiron assigns labels from 500000 downwards. All of these defaults can be changed. This could be interesting if someone wants to do an attack on your core and sees which label values are in use? Maybe.

VPNv4 table

Each PE router will receive vpnv4 updates from their peers. These vpnv4 addresses are stored in different locations on each vendors kit.

IOS keeps this information in the vpnv4 table which you can view like so:

7200_SRD_R4#sh bgp vpnv4 unicast all
BGP table version is 48, local router ID is 4.4.4.4
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
Route Distinguisher: 3.3.3.3:1
*>i6.6.6.6/32       3.3.3.3                       100      0 65123 i
*>i10.0.2.12/30     3.3.3.3                       100      0 i
Route Distinguisher: 4.4.4.4:1 (default for vrf CUS1)
*>i5.5.5.5/32       8.8.8.8                       100      0 65123 i
*>i6.6.6.6/32       3.3.3.3                       100      0 65123 i
*> 7.7.7.7/32       10.0.2.17                1         32768 ?
*>i10.0.2.12/30     3.3.3.3                       100      0 i
*> 10.0.2.16/30     0.0.0.0                  0         32768 ?
Route Distinguisher: 8.8.8.8:1
*>i5.5.5.5/32       8.8.8.8                       100      0 65123 i

The Netiron is very similar:

[email protected]_R8#sh ip bgp vpnv4 routes
Total number of BGP Routes: 4
Status A:AGGREGATE B:BEST b:NOT-INSTALLED-BEST C:CONFED_EBGP D:DAMPED
       E:EBGP H:HISTORY I:IBGP L:LOCAL M:MULTIPATH m:NOT-INSTALLED-MULTIPATH
       S:SUPPRESSED F:FILTERED s:STALE
       Prefix             Next Hop        MED        LocPrf     Weight Status
Route Distinguisher: 3.3.3.3:1
1      6.6.6.6/32         3.3.3.3                    100        0      I
         AS_PATH: 65123
2      10.0.2.12/30       3.3.3.3                    100        0      I
         AS_PATH:
Route Distinguisher: 4.4.4.4:1
3      7.7.7.7/32         4.4.4.4         1          100        0      I
         AS_PATH:
4      10.0.2.16/30       4.4.4.4         0          100        0      I
         AS_PATH:

Junos keeps this information in the bgp.l3vpn table:

USER3:R3> show route table bgp.l3vpn.0

bgp.l3vpn.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

4.4.4.4:1:7.7.7.7/32
                   *[BGP/170] 00:03:24, MED 1, localpref 100, from 4.4.4.4
                      AS path: ?
                    > to 10.0.4.14 via ae1.13, label-switched-path TO-R4
4.4.4.4:1:10.0.2.16/30
                   *[BGP/170] 00:03:28, MED 0, localpref 100, from 4.4.4.4
                      AS path: ?
                    > to 10.0.4.14 via ae1.13, label-switched-path TO-R4
8.8.8.8:1:5.5.5.5/32
                   *[BGP/170] 23:20:50, localpref 100, from 8.8.8.8
                      AS path: 65123 I
                    > to 10.0.4.14 via ae1.13, label-switched-path TO-R8

You’ll notice that Junos advertises the /30 pe-ce link by default, while the Netiron does not. IOS is advertising the /30 link as that link is in OSPF.

Route-Reflector

Routers will only keep a vpnv4 route if it has a matching route-target to install into a local VRF. This is to optimise resources. You would not want a PE router who only has three customer connected to store all 1000 vpnv4 routes from your other customers. However, if any of these routers needed to be a route-reflector it is essential to keep all these routes. If not, the router would drop all vpnv4 routes that isn’t getting placed into a local VRF (which could be all of them. In order to ensure this happens you need to configure the following:
IOS:

router bgp 100
 no bgp default route-target filter

Note that if you configure IOS as a route-filter you don’t need the above command as it’s automatic. However if you want a router to accept all vpnv4 and the router is NOT a RR, it can be handy to configure the above as a temporary measure.

Junos:

set protocols bgp group [group name] keep all

Netiron:
Not possible. I had a read through the configuration guide and also emailed a couple of guys I know in Brocade and it all came back negative :(

Static Routes

The Netiron’s location for a static route actually makes more sense, yet IOS is probably more familiar. These are static routes created on the PE routers.

Netiron:

vrf CUS1
 rd 8.8.8.8:1
 ip route 55.55.55.55/32 10.0.2.1

IOS:

ip route vrf CUS1 77.77.77.77 255.255.255.255 10.0.2.17

Junos:

USER3:R3> show configuration routing-instances CUSTOMER1
routing-options {
    static {
        route 66.66.66.66/32 next-hop 10.0.2.13;
    }
}

I’ll leave FastReroute and other advanced features for another day…

Basic MPLS L3VPN Interop – IOS, Junos, Brocade Netiron – Part 1 of 2

My first of a series of posts for MPLS interoperability between Cisco’s IOS, Juniper’s Junos, and Brocade’s Netiron code. This post will use the same core I set up before:

L3 VPN is one of the more common applications for MPLS. This post will show a very basic three customer site. I’ll leave off all the advanced stuff for another post.

All three customers are connected to different PE routers. The PE and CE devices will run a routing protocol between then and advertise their loopback addresses to the core. This will emulate the customers LAN ranges.

I’m going to run BGP on R5 and R6 as the CE-PE routing protocol and OSPF on R7. The customer is running AS #65123 and the provider AS #100.

PE MP-BGP

The first thing we need to do is set up our MP-BGP peering between our PE routers. Let’s start off with IOS as it’s what most people know:

router bgp 100
 no bgp default ipv4-unicast
 neighbor 3.3.3.3 remote-as 100
 neighbor 3.3.3.3 update-source Loopback0
 neighbor 8.8.8.8 remote-as 100
 neighbor 8.8.8.8 update-source Loopback0
 !
 address-family vpnv4
  neighbor 3.3.3.3 activate
  neighbor 3.3.3.3 send-community extended
  neighbor 8.8.8.8 activate
  neighbor 8.8.8.8 send-community extended
 exit-address-family

Junos:

USER3:R3> show configuration routing-options
autonomous-system 100;

USER3:R3> show configuration protocols bgp
group L3VPN {
    type internal;
    local-address 3.3.3.3;
    family inet-vpn {
        unicast;
    }
    neighbor 4.4.4.4;
    neighbor 8.8.8.8;
}

Netiron:

router bgp
 local-as 100
 neighbor 3.3.3.3 remote-as 100
 neighbor 3.3.3.3 update-source 8.8.8.8
 neighbor 4.4.4.4 remote-as 100
 neighbor 4.4.4.4 update-source 8.8.8.8
!
 address-family vpnv4 unicast
 neighbor 3.3.3.3 activate
 neighbor 3.3.3.3 send-community extended
 neighbor 4.4.4.4 activate
 neighbor 4.4.4.4 send-community extended
 exit-address-family

Netiron is very similar to IOS when it comes to IGP/BGP. On all three we have simply created a vpnv4 BGP session between all three PE routers. We are not running the regular IPv4 address family on these sessions. Let’s confirm.
IOS:

7200_SRD_R4#sh bgp vpnv4 unicast all summary  | beg Nei
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
3.3.3.3         4   100      46      43       18    0    0 00:19:06        0
8.8.8.8         4   100      26      23       18    0    0 00:18:59        0

Junos:

USER3:R3> show bgp summary
Groups: 1 Peers: 2 Down peers: 0
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
bgp.l3vpn.0            0          0          0          0          0          0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State
4.4.4.4                 100         43         48       0       1       19:58 Establ
  bgp.l3vpn.0: 0/0/0/0
8.8.8.8                 100       3285       3241       0       0  1d 0:25:07 Establ
  bgp.l3vpn.0: 0/0/0/0

Netiron:

[email protected]_R8#sh ip bgp vpnv4 sum | beg AS#
  Neighbor Address  AS#         State   Time          Rt:Accepted Filtered Sent     ToSend
  3.3.3.3           100         ESTAB   1d 0h26m      2           0        0        0
  4.4.4.4           100         ESTAB   0h20m43s      0           0        0        0

All of our vpn4 sessions are now up.

CE-PE – R3-R6 – Junos

R6 is a regular BGP config so I’m not pasting it here. It is simply peering with AS #100 and advertising it’s loopback address. On Junos, you configure any ce-pe protocol under the routing instance you make for your customer:

USER3:R3> show configuration routing-instances
CUSTOMER1 {
    description "Our First Customer";
    instance-type vrf;
    interface fe-0/0/3.36;
    route-distinguisher 3.3.3.3:1;
    vrf-target target:100:1;
    protocols {
        bgp {
            group EXTERNAL {
                neighbor 10.0.2.13 {
                    family inet {
                        unicast;
                    }
                    peer-as 65123;
                }
            }
        }
    }
}
USER3:R3> show bgp summary instance CUSTOMER1
Groups: 1 Peers: 1 Down peers: 0
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
CUSTO.inet.0           1          1          0          0          0          0
CUSTOM.mdt.0           0          0          0          0          0          0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State
10.0.2.13             65123         93         98       0       0       40:54 Establ
  CUSTOMER1.inet.0: 1/1/1/0
USER3:R3> show route table CUSTOMER1 6.6.6.6

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

6.6.6.6/32         *[BGP/170] 00:30:52, localpref 100
                      AS path: 65123 I
                    > to 10.0.2.13 via fe-0/0/3.36

CE-PE – R4-R7 – IOS

R7 is a simple OSPF config over area 0 advertising it’s loopback interface. The PE router is configured like so:

ip vrf CUS1
 rd 4.4.4.4:1
 route-target export 100:1
 route-target import 100:1
!
interface FastEthernet1/0.47
 encapsulation dot1Q 47
 ip vrf forwarding CUS1
 ip address 10.0.2.18 255.255.255.252
 ip ospf network point-to-point
 ip ospf 2 area 0
!
router ospf 2 vrf CUS1
 redistribute bgp 100 subnets
!
router bgp 100
 !
 address-family ipv4 vrf CUS1
  no synchronization
  redistribute ospf 2 vrf CUS1
 exit-address-family
7200_SRD_R4#sh ip ospf neighbor fa0/0.47

Neighbor ID     Pri   State           Dead Time   Address         Interface
7.7.7.7           0   FULL/  -        00:00:39    10.0.2.17       FastEthernet1/0.47
7200_SRD_R4#sh ip route vrf CUS1 7.7.7.7

Routing Table: CUS1
Routing entry for 7.7.7.7/32
  Known via "ospf 2", distance 110, metric 1, type intra area
  Redistributing via bgp 100
  Advertised by bgp 100
  Last update from 10.0.2.17 on FastEthernet1/0.47, 00:32:06 ago
  Routing Descriptor Blocks:
  * 10.0.2.17, from 7.7.7.7, 00:32:06 ago, via FastEthernet1/0.47
      Route metric is 1, traffic share count is 1

CE-PE – R8-R5 – Netiron

Standard config on the CE router once again. PE router configured as follows:

vrf CUS1
 rd 8.8.8.8:1
 address-family ipv4
   route-target export 100:1
   route-target import 100:1
 exit-address-family
exit-vrf
!
interface ve35
 vrf forwarding CUS1
 ip address 10.0.2.2/30
!
router bgp

 address-family ipv4 unicast vrf CUS1
 neighbor 10.0.2.1 remote-as 65123
 exit-address-family
[email protected]_R8#show ip bgp vrf CUS1 summary | beg AS#
  Neighbor Address  AS#         State   Time          Rt:Accepted Filtered Sent     ToSend
  10.0.2.1          65123       ESTAB   0h18m57s      1           0        4        0
[email protected]_R8#sh ip route vrf CUS1 5.5.5.5 | beg Des
        Destination        Gateway         Port          Cost          Type Uptime src-vrf
1       5.5.5.5/32         10.0.2.1        ve 35         20/0          Be   10m58s -

At this point each PE router is running their PE-CE protocol with their CE peer and learning the loopback address. Without configuring anything else, do we see any of the routes from the other PE devices?

USER3:R3> show route table CUSTOMER1 7.7.7.7

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

7.7.7.7/32         *[BGP/170] 00:31:46, MED 1, localpref 100, from 4.4.4.4
                      AS path: ?
                    > to 10.0.4.14 via ae1.13, label-switched-path TO-R4

USER3:R3> show route table CUSTOMER1 5.5.5.5

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

5.5.5.5/32         *[BGP/170] 00:21:03, localpref 100, from 8.8.8.8
                      AS path: 65123 I
                    > to 10.0.4.14 via ae1.13, label-switched-path TO-R8

Junos sees both loopbacks. Note too that the next-hops are both via LSPs. One to R4 and one to R8.

[email protected]_R8#show ip route vrf CUS1  6.6.6.6
Type Codes - B:BGP D:Connected I:ISIS O:OSPF R:RIP S:Static; Cost - Dist/Metric
BGP  Codes - i:iBGP e:eBGP
ISIS Codes - L1:Level-1 L2:Level-2
OSPF Codes - i:Inter Area 1:External Type 1 2:External Type 2 s:Sham Link
STATIC Codes - d:DHCPv6
        Destination        Gateway         Port          Cost          Type Uptime src-vrf
1       6.6.6.6/32         DIRECT          lsp TO-R3     200/0         Bi   42m12s -
[email protected]_R8#show ip route vrf CUS1 7.7.7.7
Type Codes - B:BGP D:Connected I:ISIS O:OSPF R:RIP S:Static; Cost - Dist/Metric
BGP  Codes - i:iBGP e:eBGP
ISIS Codes - L1:Level-1 L2:Level-2
OSPF Codes - i:Inter Area 1:External Type 1 2:External Type 2 s:Sham Link
STATIC Codes - d:DHCPv6
        Destination        Gateway         Port          Cost          Type Uptime src-vrf
1       7.7.7.7/32         DIRECT          lsp TO-R4     200/1         Bi   33m17s -

Netiron also sees both with a next-hop of each respective LSP.

7200_SRD_R4#sh ip route vrf CUS1 6.6.6.6

Routing Table: CUS1
Routing entry for 6.6.6.6/32
  Known via "bgp 100", distance 200, metric 0
  Tag 65123, type internal
  Redistributing via ospf 2
  Advertised by ospf 2 subnets
  Last update from 3.3.3.3 00:46:36 ago
  Routing Descriptor Blocks:
  * 3.3.3.3 (default), from 3.3.3.3, 00:46:36 ago
      Route metric is 0, traffic share count is 1
      AS Hops 1
      Route tag 65123
      MPLS Required
7200_SRD_R4#
7200_SRD_R4#sh ip route vrf CUS1 5.5.5.5

Routing Table: CUS1
Routing entry for 5.5.5.5/32
  Known via "bgp 100", distance 200, metric 0
  Tag 65123, type internal
  Redistributing via ospf 2
  Advertised by ospf 2 subnets
  Last update from 8.8.8.8 00:24:47 ago
  Routing Descriptor Blocks:
  * 8.8.8.8 (default), from 8.8.8.8, 00:24:47 ago
      Route metric is 0, traffic share count is 1
      AS Hops 1
      Route tag 65123
      MPLS Required

IOS has the routes, but there is an issue. IOS does not use the RSVP-TE tunnels for anything unless we tell it to. We can prove this to R5 like so:

7200_SRD_R4#sh ip cef vrf CUS1 5.5.5.5 detail
5.5.5.5/32, epoch 0
  recursive via 8.8.8.8 label 500000
    nexthop 10.0.4.10 FastEthernet1/0.24

Traffic would never hit the other PE routers. We need to ensure IOS actually uses these tunnels:

7200_SRD_R4#conf t
7200_SRD_R4(config)#int tun 0
7200_SRD_R4(config-if)#tunnel mpls traffic-eng autoroute announce
7200_SRD_R4(config-if)#int tun 1
7200_SRD_R4(config-if)#tunnel mpls traffic-eng autoroute announce
7200_SRD_R4#sh ip cef vrf CUS1 5.5.5.5 detail
5.5.5.5/32, epoch 0
  recursive via 8.8.8.8 label 500000
    nexthop 8.8.8.8 Tunnel1

So now our PE routers have all the required routes. They have also correctly installed these routes to go over the RSVP-TE tunnels. There is another issue to resolve though, and that’s the fact that R5 and R6 are in the same AS number. Remember with BGP, it uses the AS-PATH as a loop prevention mechanism. Therefore if R5 received a BGP update from it’s PE router with it’s own AS number in the path, that route will get dropped.
I can configure both CE routers to accept routes with their own AS number in like so:

USER5:R5> show configuration routing-options
autonomous-system 65123 loops 2;

R5 now sees R6’s route:

USER5:R5> show route 6.6.6.6

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

6.6.6.6/32         *[BGP/170] 00:03:04, localpref 100
                      AS path: 100 65123 I
                    > to 10.0.2.2 via ae1.35

But R6 still does not see R5’s route:

USER6:R6> show route 5.5.5.5

USER6:R6>

The reason why is more clear from R3, the PE’s perspective. Is R3 even advertising that route?

USER3:R3> show route advertising-protocol bgp 10.0.2.13

CUSTOMER1.inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 7.7.7.7/32              Self                                    ?
* 10.0.2.16/30            Self                                    ?

No it isn’t. Let’s go back to the Netiron and see if it was advertising everything over:

[email protected]_R8#sh ip bgp vrf CUS1 neighbors 10.0.2.1 advertised-routes
       There are 4 routes advertised to neighbor 10.0.2.1
Status A:AGGREGATE B:BEST b:NOT-INSTALLED-BEST E:EBGP I:IBGP L:LOCAL
       Prefix             Next Hop        MED        LocPrf     Weight Status
1      10.0.2.12/30       10.0.2.2                              0      BI
         AS_PATH: 100
2      10.0.2.16/30       10.0.2.2        0                     0      BI
         AS_PATH: 100
3      7.7.7.7/32         10.0.2.2        1                     0      BI
         AS_PATH: 100
4      6.6.6.6/32         10.0.2.2                              0      BI
         AS_PATH: 100 65123

The Netiron was always sending everything. Initially R5 was simply dropping those updates. As an optimisation, Junos will not bother advertising a route with the same AS path as the session as it knows the other side will just drop it. So why bother time advertising it to begin with? You need to specifically tell Junos to advertise under these circumstances:

USER3:R3# set routing-instances CUSTOMER1 protocols bgp group EXTERNAL advertise-peer-as

R6 now received the route:

USER6:R6> show route 5.5.5.5

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

5.5.5.5/32         *[BGP/170] 00:00:20, localpref 100
                      AS path: 100 65123 I
                    > to 10.0.2.14 via ae1.36

That’s it for part one. If I don’t split this post I’ll never get it finished. If you’ve made it this far, congratulations! :)

You can find part 2 over here: http://mellowd.co.uk/ccie/?p=3456

MPLS RSVP tunnels between Cisco IOS, Junos, & Brocade Netiron – Part 2

While my previous post showed how to create RSVP tunnels between these three providers, I did not mention some of the caveats between these devices.

The biggest thing is that even if you hard code paths through the network, the tunnels on IOS will refuse to come up until traffic engineering is actually running on the IGP and the required interfaces.

Let’s use the same topology as last time:

I’m going to disable traffic engineering on R2. I’m also going to run a debug mpls traffic-eng tunnels signalling detail

USER2:R2# delete protocols ospf traffic-engineering

[edit]
USER2:R2# commit and-quit

Straight away, I see this output on the 7200:

*Feb 20 18:09:40.646: LSP-TUNNEL-SIG: Tunnel0 [7]: path verification failed (unprotected)
 [Can't use link 10.0.4.9 on node 4.4.4.4]
*Feb 20 18:09:40.650: LSP-TUNNEL-SIG: tunnel Tunnel0 [7]: RSVP head-end close
*Feb 20 18:09:40.650: LSP-TUNNEL-SIG: received DELETE RESV request for tunnel 4.4.4.4 0 [7]
*Feb 20 18:09:40.650: LSP-TUNNEL-SIG: tunnel 4.4.4.4 0 [7]: path next hop is 10.0.4.10 (Fa0/0.24)
*Feb 20 18:09:40.650: LSP-TUNNEL-SIG: sending DELETE RESV reply for tunnel 4.4.4.4 0 [7]
*Feb 20 18:09:40.650: LSP-TUNNEL-SIG: Tunnel0 [7] notified of disappearing label information
*Feb 20 18:09:40.650: LSP-TUNNEL-SIG: Tunnel0 [7] label information Changed
*Feb 20 18:09:40.650: LSP-TUNNEL-SIG: Tunnel1 [7]: path verification failed (unprotected)
 [Can't use link 10.0.4.9 on node 4.4.4.4]
*Feb 20 18:09:40.654: LSP-TUNNEL-SIG: tunnel Tunnel1 [7]: RSVP head-end close
*Feb 20 18:09:40.654: LSP-TUNNEL-SIG: received DELETE RESV request for tunnel 4.4.4.4 1 [7]
*Feb 20 18:09:40.654: LSP-TUNNEL-SIG: tunnel 4.4.4.4 1 [7]: path next hop is 10.0.4.10 (Fa0/0.24)
*Feb 20 18:09:40.654: LSP-TUNNEL-SIG: sending DELETE RESV reply for tunnel 4.4.4.4 1 [7]
*Feb 20 18:09:40.654: LSP-TUNNEL-SIG: Tunnel1 [7] notified of disappearing label information
*Feb 20 18:09:40.658: LSP-TUNNEL-SIG: Tunnel1 [7] label information Changed
*Feb 20 18:09:45.658: RT: updating ospf 8.8.8.8/32 (0x0) via 10.0.4.10 Fa0/0.24
*Feb 20 18:09:45.658: RT: add 8.8.8.8/32 via 10.0.4.10, ospf metric [110/3]
*Feb 20 18:09:45.658: RT: del 8.8.8.8 via 8.8.8.8, ospf metric [110/3]
*Feb 20 18:09:45.658: RT: updating ospf 3.3.3.3/32 (0x0) via 10.0.4.10 Fa0/0.24
*Feb 20 18:09:45.658: RT: add 3.3.3.3/32 via 10.0.4.10, ospf metric [110/3]
*Feb 20 18:09:45.658: RT: del 3.3.3.3 via 3.3.3.3, ospf metric [110/3]
*Feb 20 18:09:45.658: RT: updating ospf 2.2.2.2/32 (0x0) via 10.0.4.10 Fa0/0.24
*Feb 20 18:09:45.658: RT: updating ospf 1.1.1.1/32 (0x0) via 10.0.4.10 Fa0/0.24
*Feb 20 18:09:45.658: RT: updating ospf 172.16.2.0/24 (0x0) via 10.0.4.10 Fa0/0.24
*Feb 20 18:09:45.658: RT: updating ospf 172.16.1.0/24 (0x0) via 10.0.4.10 Fa0/0.24
*Feb 20 18:09:45.658: RT: updating ospf 172.16.0.12/30 (0x0) via 10.0.4.10 Fa0/0.24
*Feb 20 18:09:45.658: RT: add 172.16.0.12/30 via 10.0.4.10, ospf metric [110/4]
*Feb 20 18:09:45.658: RT: del 172.16.0.12 via 3.3.3.3, ospf metric [110/4]
*Feb 20 18:09:45.662: RT: updating ospf 22.22.22.0/24 (0x0) via 10.0.4.10 Fa0/0.24
*Feb 20 18:09:45.662: RT: updating ospf 10.0.5.0/24 (0x0) via 10.0.4.10 Fa0/0.24
*Feb 20 18:09:45.662: RT: updating ospf 10.0.4.12/30 (0x0) via 10.0.4.10 Fa0/0.24
*Feb 20 18:09:45.662: RT: updating ospf 192.168.1.0/30 (0x0) via 10.0.4.10 Fa0/0.24
*Feb 20 18:09:45.662: RT: updating ospf 10.0.4.4/30 (0x0) via 10.0.4.10 Fa0/0.24
*Feb 20 18:09:55.390: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
*Feb 20 18:09:55.390: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to down
*Feb 20 18:09:55.390: is_up: 0 state: 4 sub state: 1 line: 0
*Feb 20 18:09:55.390: RT: interface Tunnel0 removed from routing table
*Feb 20 18:09:55.390: is_up: 0 state: 4 sub state: 1 line: 0
*Feb 20 18:09:55.390: RT: interface Tunnel1 removed from routing table

IOS really doesn’t like it at all. However only tunnels originating from R4 actually have this issue. If you check the LSPs on R4, you can see the two incoming tunnels are still fine:

7200_SRD_R4#sh mpls traffic-eng tun brief
Signalling Summary:
    LSP Tunnels Process:            running
    Passive LSP Listener:           running
    RSVP Process:                   running
    Forwarding:                     enabled
    Periodic reoptimization:        every 3600 seconds, next in 822 seconds
    Periodic FRR Promotion:         Not Running
    Periodic auto-bw collection:    every 300 seconds, next in 222 seconds
TUNNEL NAME                      DESTINATION      UP IF     DOWN IF   STATE/PROT
7200_SRD_R4_t0                   3.3.3.3          -         unknown   up/down
7200_SRD_R4_t1                   8.8.8.8          -         unknown   up/down
TO-R4                            4.4.4.4          Fa0/0.24  -         up/up
TO-R4                            4.4.4.4          Fa0/0.24  -         up/up

Even MPLS pings work TO R4:

[email protected]_R8#ping mpls rsvp lsp TO-R4

Send 5 96-byte MPLS Echo Requests over RSVP LSP TO-R4, timeout 5000 msec
Type Control-c to abort
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max=0/1/1 ms.
USER3:R3> ping mpls rsvp TO-R4
!!!!!
--- lsping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss

The Juniper and Brocade are happy to run without any TE extensions on the IGP.

Brocade and Juniper both record the path along the way to the other side by default. Cisco does not. You can however turn it on in IOS.
Brocade:

[email protected]_R8#sh mpls lsp detail
LSP TO-R3, to 3.3.3.3
  From: 8.8.8.8, admin: UP, status: UP, tunnel interface(primary path): tnl0
  [etc etc]
   Recorded routes:
    Protection codes/Rtr Id flag: P: Local  N: Node  B: Bandwidth  I: InUse R: RtrId
    192.168.1.1 -> 10.0.4.5 -> 10.0.4.13

Juniper:

USER3:R3> show mpls lsp detail
Ingress LSP: 2 sessions

4.4.4.4
  From: 3.3.3.3, State: Up, ActiveRoute: 0, LSPname: TO-R4
  [etc etc]
    Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
          10.0.4.14 10.0.4.6 10.0.4.9

Cisco:

7200_SRD_R4#sh mpls traffic-eng tunnels | include Record
      Record   Route:

7200_SRD_R4#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
7200_SRD_R4(config-if)#int tun 1
7200_SRD_R4(config-if)#tunnel mpls traffic-eng record-route
7200_SRD_R4(config-if)#end

7200_SRD_R4#sh mpls traffic-eng tunnels | include Record
      Record   Route:  10.0.4.10 192.168.1.2

UPDATE (24/02/13)
Note that there is a way on IOS to get the tunnel up without running TE on your IGP. You need to specify the verbatim keyword on the path option. This only works with an explicit path (though it could be strict or loose) and is only supported on certain versions of IOS. More info here:http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/fsvbmlsp.html

MPLS RSVP tunnels between Cisco IOS, Junos, & Brocade Netiron

I wanted to test inter-vendor MPLS L3VPN compatibility between Brocade, Cisco, and Juniper. The ‘core’ itself will be Junos. In a future post I’ll probably have a random Brocade/Cisco device in the core as well to show how that works. This post will be the basis for a number of future posts on various MPLS applications. I wanted to have the core itself all done so that’s what I’ll crack on with on this post.

 

I’ll be running RSVP TE tunnels between my PE routers. The core devices will also be running RSVP of course. For this lab I’m just using OSPF as my core IGP.

 

Let’s use the following topology:

R4 is a Cisco 7200 running advanced IP services version 12.2(33)SRD4
R8 is a Brocade Netiron XMR running 5.4b
All the other routers are M10s running 10.4R12.4

R6, R7, and R5 are my CPE routers – Note that they will not be used for this post, only future posts. R3, R4, and R8 are the PE routers. R1 and R2 are the P routers.

Core

As always with MPLS, the P routers config is very minimal. All the core interfaces are configured like so:

interfaces {
    fe-0/0/3 {
        unit 12 {
            vlan-id 12;
            family inet {
                address 10.0.4.6/30;
            }
            family mpls;

Family MPLS has to be configured on all core interfaces. My protocols config on R2 is like so:

USER2:R2> show configuration protocols
rsvp {
    interface fe-1/0/2.0;
    interface fe-0/0/3.12;
    interface fe-0/0/3.24;
}
mpls {
    interface fe-1/0/2.0;
    interface fe-0/0/3.24;
    interface fe-0/0/3.12;
}
ospf {
    traffic-engineering;
    area 0.0.0.0 {
        interface all;
    }
}

R1 has got a very similar config so I’m not pasting it here.

Junos PE

Family MPLS needs to be configured on the core facing interfaces. The rest of the relevant config for my set up is as follows:

USER3:R3> show configuration protocols
rsvp {
    interface fe-1/0/3.13;
}
mpls {
    no-cspf;
    label-switched-path TO-R4 {
        to 4.4.4.4;
        primary TO-R4;
    }
    label-switched-path TO-R8 {
        to 8.8.8.8;
        primary TO-R8;
    }
    path TO-R4 {
        4.4.4.4 loose;
    }
    path TO-R8 {
        8.8.8.8 loose;
    }
    interface fe-1/0/3.13;
}
ospf {
    traffic-engineering;
    area 0.0.0.0 {
        interface all;
        interface fe-0/0/3.36 {
            disable;
        }
    }
}

I’ve enabled loose paths to the loopbacks of the other 2 PE routers. OSPF TE is turned on and RSVP and MPLS are switched onto the relevant interfaces.

Brocade Netiron PE

There is no need to configure anything specific on the actual MPLS interfaces for Brocade. You simply need to add the core facing interfaces to the MPLS configuration stanza.

router ospf 
 area 0
!
router mpls
 policy
  traffic-eng ospf area 0

 path TO-R3
  loose 3.3.3.3

 path TO-R4
  loose 4.4.4.4

 mpls-interface ve2

 lsp TO-R3
  to 3.3.3.3
  primary TO-R3
  enable

 lsp TO-R4
  to 4.4.4.4
  primary TO-R4
  enable

Cisco IOS PE

With IOS, you need to ensure CEF is enabled. You also need to turn mpls traffic-engineering tunnels on globally, as well as on each core facing interface:

ip cef
!
mpls traffic-eng tunnels
!
interface Tunnel0
 ip unnumbered Loopback0
 tunnel destination 3.3.3.3
 tunnel mode mpls traffic-eng
 tunnel mpls traffic-eng path-option 10 dynamic
!
interface Tunnel1
 ip unnumbered Loopback0
 tunnel destination 8.8.8.8
 tunnel mode mpls traffic-eng
 tunnel mpls traffic-eng path-option 10 dynamic
!
router ospf 1
 router-id 4.4.4.4
 log-adjacency-changes
 mpls traffic-eng router-id Loopback0
 mpls traffic-eng area 0

Verification

The output of various show commands are of course different on each platform. I’ll be showing the actual LSP as well as do some MPLS traceroutes to show how each gives up information. The ‘detail’ switch on the LSPs throws out tons of information so I’ll add those on a later post. The main thing we are concerned about now is just to ensure the LSPs are in fact ‘up’

Brocade:

[email protected]_R8#sh mpls lsp
Note: LSPs marked with * are taking a Secondary Path
                               Admin Oper  Tunnel   Up/Dn Retry Active
Name           To              State State Intf     Times No.   Path
TO-R3          3.3.3.3         UP    UP    tnl0     1     0     TO-R3
TO-R4          4.4.4.4         UP    UP    tnl1     2     0     TO-R4

Junos:

USER3:R3> show mpls lsp
Ingress LSP: 2 sessions
To              From            State Rt P     ActivePath       LSPname
4.4.4.4         3.3.3.3         Up     0 *     TO-R4            TO-R4
8.8.8.8         3.3.3.3         Up     0 *     TO-R8            TO-R8
Total 2 displayed, Up 2, Down 0

Egress LSP: 2 sessions
To              From            State   Rt Style Labelin Labelout LSPname
3.3.3.3         4.4.4.4         Up       0  1 SE       3        - C7200_12.2SRD_t0
3.3.3.3         8.8.8.8         Up       0  1 FF       3        - TO-R3
Total 2 displayed, Up 2, Down 0

Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0

Cisco:

C7200_12.2SRD#sh mpls traffic-eng tunnels brief
Signalling Summary:
    LSP Tunnels Process:            running
    Passive LSP Listener:           running
    RSVP Process:                   running
    Forwarding:                     enabled
    Periodic reoptimization:        every 3600 seconds, next in 3315 seconds
    Periodic FRR Promotion:         Not Running
    Periodic auto-bw collection:    every 300 seconds, next in 15 seconds
TUNNEL NAME                      DESTINATION      UP IF     DOWN IF   STATE/PROT
C7200_12.2SRD_t0                 3.3.3.3          -         Fa0/0.24  up/up
C7200_12.2SRD_t1                 8.8.8.8          -         Fa0/0.24  up/up
TO-R4                            4.4.4.4          Fa0/0.24  -         up/up
TO-R4                            4.4.4.4          Fa0/0.24  -         up/up

Both Cisco and Juniper show both outbound and inbound tunnels. The Brocade only shows outgoing tunnels in the brief output. The P routers will show transit tunnels like so:

USER2:R2> show mpls lsp
Ingress LSP: 0 sessions
Total 0 displayed, Up 0, Down 0

Egress LSP: 0 sessions
Total 0 displayed, Up 0, Down 0

Transit LSP: 6 sessions
To              From            State   Rt Style Labelin Labelout LSPname
3.3.3.3         4.4.4.4         Up       0  1 SE  300016   299872 C7200_12.2SRD_t0
3.3.3.3         8.8.8.8         Up       0  1 FF  299824   299792 TO-R3
4.4.4.4         8.8.8.8         Up       0  1 FF  300048        0 TO-R4
4.4.4.4         3.3.3.3         Up       0  1 FF  300032        0 TO-R4
8.8.8.8         4.4.4.4         Up       0  1 SE  300000        3 C7200_12.2SRD_t1
8.8.8.8         3.3.3.3         Up       0  1 FF  299856        3 TO-R8
Total 6 displayed, Up 6, Down 0

It’s pretty clear from the output above that LSPs are unidirectional and hence each PE-PE link is actually 2 LSPs, 1 in either direction.

You can also use MPLS pings and traceroutes. This is the output of a couple of MPLS RSVP traceroutes:

Brocade:

[email protected]_R8#traceroute mpls rsvp lsp TO-R3

Trace RSVP LSP TO-R3, timeout 5000 msec, TTL 1 to 30
Type Control-c to abort
 1  1ms 2.2.2.2 return code 8(Transit)
 2  1ms 1.1.1.1 return code 8(Transit)
 3  1ms 3.3.3.3 return code 3(Egress)

Cisco:

C7200_12.2SRD#traceroute mpls traffic-eng tunnel 0
Tracing MPLS TE Label Switched Path on Tunnel0, timeout is 2 seconds

Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
  'L' - labeled output interface, 'B' - unlabeled output interface,
  'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
  'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry,
  'P' - no rx intf label prot, 'p' - premature termination of LSP,
  'R' - transit router, 'I' - unknown upstream index,
  'X' - unknown return code, 'x' - return code 0

Type escape sequence to abort.
  0 10.0.4.9 MRU 1500 [Labels: 300016 Exp: 0]
L 1 2.2.2.2 MRU 1518 [Labels: 299872 Exp: 7] 36 ms
L 2 1.1.1.1 MRU 1518 [Labels: implicit-null Exp: 0] 24 ms
! 3 3.3.3.3 1 ms

Juniper:

USER3:R3> traceroute mpls rsvp TO-R8
  Probe options: retries 3, exp 7

  ttl    Label  Protocol    Address          Previous Hop     Probe Status
    1   299824  RSVP-TE     10.0.4.14        (null)           Success
    2   299856  RSVP-TE     10.0.4.6         10.0.4.14        Success
    3        3  RSVP-TE     192.168.1.2      10.0.4.6         Egress

  Path 1 via fe-1/0/3.13 destination 127.0.0.64

All slightly different info, but the same end result. All of the vendors have detail switches which shows a lot more information.

So there you have it. I have all the RSVP tunnels up between all my PE routers and all is well. As noted before, this post will form the basis of a series of posts of various MPLS applications.