Life is a Roller Coaster

September 22, 2008

Multicast VPN (Rosen Draft)

Filed under: Technical section — Tags: — adisubrata @ 6:41 AM

In this post I will talk about VPN Multicast, Rosen draft. It will cover basic configuration VPN multicast. The topology of this test is similar with the previous post PIM-SM. In order to simulate the multicast under VRF, there is additional CE router behind the PEs (R1, R5 and R5). There are 2 RPs set, C-RP and S-RP. Multicast VPN draft Rosen having some constraints such as Core must have PIM-SM with RP, no TE support, etc. You can see the complete configuration at the end of this post.

C-RP belongs to VRF and S-RP belongs to service provider. Multicast tunnel are needed on each PE and RP, you must have Tunnel PIC or another service PIC to support this MT interface. MT interface will setup automatically when you configure MDT (vpn-group-address).

C-RP IP address is 10.10.10.10 which is IP address of Lo0 VRF on R1. S-RP is 10.0.3.5.

CE1 and CE2 will have static routes to R1 and R5. CE3 will use BGP to connect to R6.

VRF name on R1 is rosen-1, R2 is rosen-2 and R3 is rosen-3

The configuration is quite similar with Multicast PIM-SM except VRF configuration. You will need to configure secondary loopback for each PE inside VRF like show below:

enugadi@M7i# show interfaces lo0 
unit 0 {
    family inet {
        address 10.0.6.1/32 {
            primary;
        }
    }
    family iso {
        address 49.0001.1111.1111.1111.00;
    }
}
unit 14 {
    family inet {
        address 10.10.10.10/32;
    }
}

Lo0.14 will used as VRF’s Lo0.

Below is the VRF configuration on R1:

rosen-1 {
    instance-type vrf;
    interface lo0.14;
    interface vt-1/2/0.0;
    interface ge-0/0/1.24;
    vrf-target target:65412:1;
    routing-options {
        static {
            route 10.0.5.0/24 next-hop 172.16.40.2;
            route 11.11.11.11/32 next-hop 172.16.40.2;
        }
    }
    protocols {
        pim {
            vpn-group-address 225.0.0.0;
            rp {
                local {
                    address 10.10.10.10;
                }
            }
            interface all {
                mode sparse;
            }
            interface lo0.14 {
                mode sparse;
            }
        }
    }
}

Multicast sender 10.0.5.200 will send multicast data to CE1:

enugadi@M7i# run show multicast route logical-router ce1
Family: INET

Group: 225.0.0.1
    Source: 10.0.5.200/32
    Upstream interface: fe-1/3/0.0
    Downstream interface list:
        ge-0/0/0.24

Family: INET6

enugadi@M7i# run show multicast route logical-router ce1 detail
Family: INET

Group: 225.0.0.1
    Source: 10.0.5.200/32
    Upstream interface: fe-1/3/0.0
    Downstream interface list:
        ge-0/0/0.24
    Session description: MALLOC
    Statistics: 125 kBps, 92 pps, 72198 packets
    Next-hop ID: 262151
    Upstream protocol: PIM

Family: INET6

enugadi@M7i# run show route table inet.1 logical-router ce1 

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

225.0.0.1,10.0.5.200/32*[PIM/105] 00:13:15
                      Multicast (IPv4)

Vpn-group-address is the MDT of this multicast VRF.

On R1, verify PIM (*,G) and (S,G) mesh for MDT:

enugadi@M7i# run show pim join extensive
Instance: PIM.master Family: INET

Group: 225.0.0.0
    Source: *
    RP: 10.0.3.5                            P-RP IP Address
    Flags: sparse,rptree,wildcard
    Upstream interface: ge-0/0/0.1          RPF interface to P-RP
    Upstream neighbor: 10.0.4.13           RPF neighbor to P-RP
    Upstream state: Join to RP
    Downstream neighbors:
        Interface: mt-1/2/0.32768          GRE tunnel interface toward VRF
            10.10.10.10 State: Join Flags: SRW  Timeout: Infinity

Group: 225.0.0.0
    Source: 10.0.3.5                        Lo0 of R5 (PE receiver) address
    Flags: sparse,spt
    Upstream interface: ge-0/0/0.1          RPF interface to P-
    Upstream neighbor: 10.0.4.13            RPF neighbor to P-RP
    Upstream state: Join to Source
    Keepalive timeout: 325
    Downstream neighbors:
        Interface: mt-1/2/0.32768
            10.10.10.10 State: Join Flags: S   Timeout: Infinity

Group: 225.0.0.0
    Source: 10.0.6.1                        Local Loopback address
    Flags: sparse,spt
    Upstream interface: Local
    Upstream neighbor: Local
    Upstream state: Local Source, Prune to RP
    Keepalive timeout: 325
    Downstream neighbors:
        Interface: ge-0/0/0.1
            10.0.4.13 State: Join Flags: S Timeout: 178
        Interface: mt-1/2/0.32768            GRE tunnel interface toward VRF
            10.10.10.10 State: Join Flags: S   Timeout: Infinity

Group: 225.0.0.0
    Source: 10.0.9.6                         Lo0 of R6 (PE receiver) address
    Flags: sparse,spt
    Upstream interface: ge-0/0/0.1
    Upstream neighbor: 10.0.4.13
    Upstream state: Join to Source
    Keepalive timeout: 325
    Downstream neighbors:
        Interface: mt-1/2/0.32768
            10.10.10.10 State: Join Flags: S   Timeout: Infinity

Instance: PIM.master Family: INET6

Verify GRE tunnel between each VRF

enugadi@M7i# run show pim neighbors instance rosen-1
Instance: PIM.rosen-1

Interface           IP V Mode        Option      Uptime Neighbor addr
ge-0/0/1.24          4 2             HPLG      00:26:56 172.16.40.2
mt-1/2/0.32768       4 2             HPLG      00:00:04 50.50.50.50
mt-1/2/0.32768       4 2             HPLG      00:26:20 60.60.60.60    

[edit]
enugadi@M7i# run show pim neighbors logical-router r5 instance rosen-2
Instance: PIM.rosen-2

Interface           IP V Mode        Option      Uptime Neighbor addr
ge-0/0/0.25          4 2             HPLG      00:00:18 172.16.50.2
mt-1/2/0.35840       4 2             HPLG      00:00:10 10.10.10.10
mt-1/2/0.35840       4 2             HPLG      00:00:11 60.60.60.60    

[edit]
enugadi@M7i# run show pim neighbors logical-router r6 instance rosen-3
Instance: PIM.rosen-3

Interface           IP V Mode        Option      Uptime Neighbor addr
ge-0/0/0.19          4 2             HPLG      00:27:06 172.16.0.10
mt-1/2/0.41984       4 2             HPLG      00:27:00 10.10.10.10
mt-1/2/0.41984       4 2             HPLG      00:00:15 50.50.50.50





Since CE3 has no receiver, I configured static IGMP join on CE3. Below is the configuration:

enugadi@M7i# show logical-routers ce3 protocols igmp
interface ge-0/0/1.19 {
    static {
        group 225.0.0.1 {
            source 10.0.5.200;
        }
    }
}

enugadi@M7i# run show igmp group logical-router ce3
Interface: ge-0/0/1.19
    Group: 225.0.0.1
        Source: 10.0.5.200
        Last reported by: Local
        Timeout:       0 Type: Static
Interface: local
    Group: 224.0.0.2
        Source: 0.0.0.0
        Last reported by: Local
        Timeout:       0 Type: Dynamic
    Group: 224.0.0.22
        Source: 0.0.0.0
        Last reported by: Local
        Timeout:       0 Type: Dynamic





Verify multicast usage on R1, R5 and R6:

enugadi@M7i# run show multicast route detail
Family: INET

Group: 225.0.0.0
    Source: 10.0.3.5/32
    Upstream interface: ge-0/0/0.1
    Downstream interface list:
        mt-1/2/0.49152
    Session description: MALLOC
    Statistics: 0 kBps, 0 pps, 154 packets
    Next-hop ID: 262155
    Upstream protocol: PIM

Group: 225.0.0.0
    Source: 10.0.6.1/32
    Upstream interface: local
    Downstream interface list:
        ge-0/0/0.1
    Session description: MALLOC
    Statistics: 123 kBps, 89 pps, 265755 packets
    Next-hop ID: 262152
    Upstream protocol: PIM

Group: 225.0.0.0
    Source: 10.0.9.6/32
    Upstream interface: ge-0/0/0.1
    Downstream interface list:
        mt-1/2/0.49152
    Session description: MALLOC
    Statistics: 0 kBps, 0 pps, 151 packets
    Next-hop ID: 262155
    Upstream protocol: PIM

Family: INET6

[edit]
enugadi@M7i# run show multicast route logical-router r5 detail
Family: INET

Group: 225.0.0.0
    Source: 10.0.3.5/32
    Upstream interface: local
    Downstream interface list:
        ge-0/0/1.8
    Session description: MALLOC
    Statistics: 0 kBps, 0 pps, 70 packets
    Next-hop ID: 262156
    Upstream protocol: PIM

Group: 225.0.0.0
    Source: 10.0.6.1/32
    Upstream interface: ge-0/0/1.8
    Downstream interface list:
        mt-1/2/0.52224
    Session description: MALLOC
    Statistics: 129 kBps, 94 pps, 119287 packets
    Next-hop ID: 262149
    Upstream protocol: PIM

Group: 225.0.0.0
    Source: 10.0.9.6/32
    Upstream interface: ge-0/0/1.8
    Downstream interface list:
        mt-1/2/0.52224
    Session description: MALLOC
    Statistics: 0 kBps, 0 pps, 69 packets
    Next-hop ID: 262149
    Upstream protocol: PIM

Family: INET6

[edit]
enugadi@M7i# run show multicast route logical-router r6 detail
Family: INET

Group: 225.0.0.0
    Source: 10.0.3.5/32
    Upstream interface: ge-0/0/1.9
    Downstream interface list:
        mt-1/2/0.58368
    Session description: MALLOC
    Statistics: 0 kBps, 0 pps, 156 packets
    Next-hop ID: 262154
    Upstream protocol: PIM

Group: 225.0.0.0
    Source: 10.0.6.1/32
    Upstream interface: ge-0/0/1.9
    Downstream interface list:
        mt-1/2/0.58368
    Session description: MALLOC
    Statistics: 138 kBps, 100 pps, 268052 packets
    Next-hop ID: 262154
    Upstream protocol: PIM

Group: 225.0.0.0
    Source: 10.0.9.6/32
    Upstream interface: local
    Downstream interface list:
        ge-0/0/1.9
    Session description: MALLOC
    Statistics: 0 kBps, 0 pps, 151 packets
    Next-hop ID: 262161
    Upstream protocol: PIM


Verify Multicast usages on each CEs:
enugadi@M7i# run show multicast route logical-router ce1
Family: INET

Group: 225.0.0.1
    Source: 10.0.5.200/32
    Upstream interface: fe-1/3/0.0
    Downstream interface list:
        ge-0/0/0.24

Family: INET6

[edit]
enugadi@M7i# run show multicast route logical-router ce1 detail
Family: INET

Group: 225.0.0.1
    Source: 10.0.5.200/32
    Upstream interface: fe-1/3/0.0
    Downstream interface list:
        ge-0/0/0.24
    Session description: MALLOC
    Statistics: 139 kBps, 102 pps, 287752 packets
    Next-hop ID: 262151
    Upstream protocol: PIM

Family: INET6

[edit]
enugadi@M7i# run show multicast route logical-router ce2 detail
Family: INET

Group: 225.0.0.1
    Source: 10.0.5.200/32
    Upstream interface: ge-0/0/1.25
    Downstream interface list:
        fe-1/3/1.0
    Session description: MALLOC
    Statistics: 136 kBps, 100 pps, 272932 packets
    Next-hop ID: 262162
    Upstream protocol: PIM

Family: INET6

[edit]
enugadi@M7i# run show multicast route logical-router ce3 detail
Family: INET

Group: 225.0.0.1
    Source: 10.0.5.200/32
    Upstream interface: ge-0/0/1.19
    Session description: MALLOC
    Statistics: 133 kBps, 98 pps, 268962 packets
    Next-hop ID: 0
    Upstream protocol: PIM

Family: INET6

multicast-rosen-ce-full-config

Multicast PIM-SM

Filed under: Technical section — Tags: — adisubrata @ 4:27 AM

In this post I will share how to configure multicast IPv4 PIM-SM multicast in the Juniper router. There are five router in the simulated network R1, R3, R4, R5, and R6. I used Junos 8.4R4.2 and M7i router. You can download full configuration at the and of this post.

Since I don’t have many routers to play, I will use logical router to simulate the network and also will use real PC to simulate multicast source and receiver. Tunnel PIC (Service PIC) needed on RP and first-hop router. So if you don’t have service PIC installed, you can set the first-hop router as an RP, it should be ok since the register message will send locally. The RP is R4 with lo0 address 10.0.3.4. This network is used IGMPv2.

I use VLC software to generate multicast with address 225.0.0.1. You can set VLC to generates multicast data. Go to File>Wizard>Select your file>multicast address.

As first-hop router, R1 will send register message, we can see this message using debug as shown below:

Sep 22 03:44:06.191576 PIM SENT 10.0.6.1 -> 10.0.3.4 V2 Register Flags: 0×40000000 Border: 0 Null: 1 Source 10.0.5.200 Group 225.0.0.1 sum 0xae35 len 28
Sep 22 03:44:06.193002 PIM ge-0/0/0.3 RECV 10.0.3.4 -> 10.0.6.1 V2 RegisterStop Source 10.0.5.200 Group 225.0.0.1 sum 0xeb15 len 18

Let’s check the IGMP group on R5:
We can see that Receiver join the IGMP with (*,G) as indicated with source 0.0.0.0 and group 225.0.0.1.

enugadi@M7i# run show igmp group 225.0.0.1 logical-router r5
Interface: fe-1/3/1.0
Group: 225.0.0.1
Source: 0.0.0.0
Last reported by: 172.16.30.2
Timeout:     201 Type: Dynamic
enugadi@M7i# run monitor traffic interface fe-1/3/1
---- snipped ------
03:27:05.525416  In IP 172.16.30.2 > 225.0.0.1: igmp v2 report 225.0.0.1
03:27:06.036921  In IP 172.16.30.2 > 225.0.0.1: igmp v2 report 225.0.0.1
03:27:07.036789  In IP 172.16.30.2 > 225.0.0.1: igmp v2 report 225.0.0.1

Let’s verify multicast route on the first-hop router (R1):
As we can see below, First hop router R1 already forwarding the multicast with (S,G).

enugadi@M7i# run show multicast route logical-router r1
Family: INET

Group: 225.0.0.1
    Source: 10.0.5.200/32
    Upstream interface: fe-1/3/0.0
    Downstream interface list:
        ge-0/0/0.1

enugadi@M7i# run show pim join extensive logical-router r1
Instance: PIM.master Family: INET

Group: 225.0.0.1
    Source: 10.0.5.200
    Flags: sparse,spt
    Upstream interface: fe-1/3/0.0
    Upstream neighbor: Direct
    Upstream state: Local Source
    Keepalive timeout: 331
    Downstream neighbors:
        Interface: ge-0/0/0.1
            10.0.4.13 State: Join Flags: S Timeout: 167

Let’s verify on R3, R4 and R5:

enugadi@M7i# run show multicast route logical-router r3
Family: INET

Group: 225.0.0.1
    Source: 10.0.5.200/32
    Upstream interface: ge-0/0/1.1
    Downstream interface list:
        ge-0/0/0.7

Family: INET6

[edit]
enugadi@M7i# run show multicast route logical-router r4
Family: INET

Family: INET6

[edit]
enugadi@M7i# run show multicast route logical-router r5
Family: INET

Group: 225.0.0.1
    Source: 10.0.5.200/32
    Upstream interface: ge-0/0/1.7
    Downstream interface list:
        fe-1/3/1.0

Group: 225.0.0.1
    Source: 172.16.30.2/32
    Upstream interface: fe-1/3/1.0

Family: INET6

We do not see multicast routes on R4, it is rely on reality that multicast doesn’t flow through R4 router. The SPT build follow the shortest path between R5 and R1 which is R5—R3—R1

enugadi@M7i# run traceroute 10.0.5.200 logical-router r5
traceroute to 10.0.5.200 (10.0.5.200), 30 hops max, 40 byte packets
 1  10.0.2.2 (10.0.2.2)  0.739 ms  0.732 ms  0.659 ms <- R3
 2  10.0.4.14 (10.0.4.14)  0.711 ms  0.724 ms  0.709 ms < R1
 3  10.0.5.200 (10.0.5.200)  0.582 ms  0.577 ms  0.536 ms

Let’s see multicast routes on R5:

enugadi@M7i# run show pim join 225.0.0.1 logical-router r5 extensive
Instance: PIM.master Family: INET

Group: 225.0.0.1
    Source: *
    RP: 10.0.3.4
    Flags: sparse,rptree,wildcard
    Upstream interface: ge-0/0/1.8
    Upstream neighbor: 10.0.2.10
    Upstream state: Join to RP
    Downstream neighbors:
        Interface: fe-1/3/1.0
            172.16.30.1 State: Join Flags: SRW  Timeout: Infinity

Group: 225.0.0.1
    Source: 10.0.5.200
    Flags: sparse,spt
    Upstream interface: ge-0/0/1.7
    Upstream neighbor: 10.0.2.2
    Upstream state: Join to Source, Prune to RP
    Keepalive timeout: 310
    Downstream neighbors:
        Interface: fe-1/3/1.0
            172.16.30.1 State: Join Flags: S   Timeout: Infinity

R5 receives multicast data from SPT which is R3 and send a prune for traffic received via the RPT. This is used to eliminate inefficiency of suboptimal routing.

enugadi@M7i# run show multicast rpf logical-router r5 10.0.5.200
Multicast RPF table: inet.0 , 21 entries

10.0.5.0/24
    Protocol: IS-IS
    Interface: ge-0/0/1.7
    Neighbor: 10.0.2.2

enugadi@M7i# run show log r5/debug-multicast
Sep 22 04:13:33 M7i clear-log[7812]: logfile cleared
Sep 22 04:13:39.329118 PIM ge-0/0/1.7 SENT 10.0.2.1 -> 224.0.0.13 V2 JoinPrune to 10.0.2.2 holdtime 210 groups 1 sum 0xd81f len 34
Sep 22 04:13:39.329207 group 225.0.0.1 joins 1 prunes 0
Sep 22 04:13:39.329239   join list:
Sep 22 04:13:39.329279     source 10.0.5.200 flags sparse
Sep 22 04:13:39.332781 PIM ge-0/0/1.8 SENT 10.0.2.9 -> 224.0.0.13 V2 JoinPrune to 10.0.2.10 holdtime 210 groups 1 sum 0xd7db len 34
Sep 22 04:13:39.332873 group 225.0.0.1 joins 1 prunes 0
Sep 22 04:13:39.332903   join list:
Sep 22 04:13:39.332949     source 10.0.3.4 flags sparse,rptree,wildcard
Sep 22 04:13:39.669313 PIM ge-0/0/1.8 SENT 10.0.2.9 -> 224.0.0.13 V2 JoinPrune to 10.0.2.10 holdtime 210 groups 1 sum 0xd717 len 34
Sep 22 04:13:39.669401 group 225.0.0.1 joins 0 prunes 1
Sep 22 04:13:39.669432   prune list:
Sep 22 04:13:39.669473     source 10.0.5.200 flags sparse,rptree

Let’s check the multicast usages on R1, R3, and R5:

enugadi@M7i# run show multicast route logical-router r1 extensive
Family: INET

Group: 225.0.0.1
    Source: 10.0.5.200/32
    Upstream interface: fe-1/3/0.0
    Downstream interface list:
        ge-0/0/0.1
    Session description: MALLOC
    Statistics: 119 kBps, 87 pps, 89997 packets
    Next-hop ID: 262144
    Upstream protocol: PIM
    Route state: Active
    Forwarding state: Forwarding
    Cache lifetime/timeout: 360 seconds
    Wrong incoming interface notifications: 0

[edit logical-routers r5 protocols pim]
enugadi@M7i# run show multicast route logical-router r3 detail
Family: INET

Group: 225.0.0.1
    Source: 10.0.5.200/32
    Upstream interface: ge-0/0/1.1
    Downstream interface list:
        ge-0/0/0.7
    Session description: MALLOC
    Statistics: 134 kBps, 99 pps, 87569 packets
    Next-hop ID: 262146
    Upstream protocol: PIM

Family: INET6

[edit logical-routers r5 protocols pim]
enugadi@M7i# run show multicast route logical-router r5 detail
Family: INET

Group: 225.0.0.1
    Source: 10.0.5.200/32
    Upstream interface: ge-0/0/1.7
    Downstream interface list:
        fe-1/3/1.0
    Session description: MALLOC
    Statistics: 131 kBps, 97 pps, 87821 packets
    Next-hop ID: 262142
    Upstream protocol: PIM

Family: INET6

Multicast routes will put into the table inet.1.

enugadi@M7i# run show route logical-router r1 table inet.1    

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

225.0.0.1,10.0.5.200/32*[PIM/105] 00:33:25
                      Multicast (IPv4)

[edit]
enugadi@M7i# run show route logical-router r3 table inet.1    

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

225.0.0.1,10.0.5.200/32*[PIM/105] 00:33:27
                      Multicast (IPv4)

[edit]
enugadi@M7i# run show route logical-router r5 table inet.1    

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

225.0.0.1,10.0.5.200/32*[PIM/105] 00:33:29
                      Multicast (IPv4)

multicast-pim-sm-config

September 20, 2008

Configuring Cflowd v5

Filed under: Technical section — Tags: — adisubrata @ 1:53 AM

I will try to simulate Cflowd v5 in this post. This feature is used usually in the Internet gateway router which ISP need to detects what transit packet flow through their routers. It can be bad or good packet :) .

In JUNOS, we are able to capture the life packet using TCPDUMP as mentioned in the previous post. So what is the different between TCPDUMP and CFlowd if both them able to capture the life packets?

TCPDUMP able to capture the packet destination to the router, but TCPDUMP cannot capture the transit packet which Cflowd can do that. so TCPDUMP is used for local packet, and Cflowd is used for transit packet. More further, Cflowd can be integrated to packet analyzer which is usefull to detects attacker IP address while TCPDUMP usually only usefull for debugging purposes.

There are 2 output method you can configure in the JUNOS. Method 1 is using RE based Cflowd and and method 2 is using PIC based Cflowd. In order to support PIC based Cflowd, you must have Service PIC interface such as MS-PIC, AS-PIC and Mo PIC. MS PIC is the next generation of AS PIC. MS PIC and AS PIC using interface SP while MO PIC using interface MO. Actually there are no different between both interface to support cflowd.

So, What is the different between RE based cflowd and PIC based Cflowd ? The different is related to sampling performance. RE based Cflowd use the RE to collects the packet flow which is coming from PFE. Remember that PFE and RE is connected using interface fxp1. The performance related with how much packet can be collected using RE and PIC. When you need to collected huge packet on cflowd, you will definitely need PIC based Cflowd. In other word, RE is used for low performance sampling and PIC is used for high performance sampling.

Personally, I used RE based Cflowd only for debugging purpose, and I used rate 10k.

Below is the summarize of Cflowd v5 flow Information.

v5 flow entry
Src addr: 10.53.127.1
Dst addr: 10.6.255.15
Nhop addr: 192.168.255.240
Input interface: 5
Output interface: 3
Pkts in flow: 15
Bytes in flow: 600
Start time of flow: 7230
End time of flow: 7271
Src port: 26629
Dst port: 179
TCP flags: 0×10
IP proto num: 6
TOS: 0xc0
Src AS: 7018
Dst AS: 11111
Src netmask len: 16
Dst netmask len: 0

Basic configuration:

Cflowd configuration

enugadi@M7i# show forwarding-options
sampling {
    traceoptions {
        file debug-flow;
    }
    input {
        family inet {
            rate 1;
            run-length 0;
            max-packets-per-second 65535;
        }
    }
    output {
        cflowd 192.168.150.100 {
            port 2055;
            version 5;
            autonomous-system-type origin;
        }
        interface sp-0/1/0 {
            source-address 172.16.40.1;
        }
    }
}

Service Interface configuration

enugadi@M7i# show interfaces sp-0/1/0
unit 0 {
    family inet;
}

[edit]
enugadi@M7i# show interfaces ge-0/0/0.1
vlan-id 1;
family inet {
sampling {
input;
output;
}
address 10.0.4.14/30;
}
family iso;
family mpls;

Verification:

enugadi@M7i# run show services accounting flow
Service Accounting interface: sp-0/1/0, Local interface index: 133
Service name: (default sampling)
Interface state: Accounting
  Flow information
    Flow packets: 1664, Flow bytes: 107389
    Flow packets 10-second rate: 0, Flow bytes 10-second rate: 64
    Active flows: 0, Total flows: 33
    Flows exported: 39, Flows packets exported: 24
    Flows inactive timed out: 33, Flows active timed out: 6

If you find interface state is in “NOT ACCOUNTING“, you have to check services pic configuration and adding family INET to your service PIC configuration.

Example:

enugadi@M7i# show interfaces sp-0/1/0
unit 0 {
    family inet;
}
enugadi@M7i# run show services accounting status
Service Accounting interface: sp-0/1/0, Local interface index: 133
Service name: (default sampling)
Interface state: Accounting
  Service ID: 0
  Export interval (in seconds): 60, Export format: cflowd v5
  Protocol: IPv4, Engine type: 188, Engine ID: 17
  Route record count: 11, IFL to SNMP index count: 51, AS count: 3
  Time set: Yes, Configuration set: Yes
  Route record set: Yes, IFL SNMP map set: Yes

I will try to simulate 10000 packets and let see what recorded on the flow server are:

enugadi@M7i# run ping 50.50.50.50 logical-router ce1 rapid count 10000 source 11.11.11.11 PING 50.50.50.50 (50.50.50.50):
56 data bytes
--- snipped ----
--- 50.50.50.50 ping statistics ---
10000 packets transmitted, 10000 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.942/1.141/44.862/1.629 ms

Since the flowd rate is 1, so every single packets flow will count in the database.

Let’s check the captured packet from CLI:

enugadi@M7i# run show services accounting flow-detail detail
Service Accounting interface: sp-0/1/0, Local interface index: 133
Service name: (default sampling)
Interface state: Accounting
Protocol   Input          Source          Source   Output          Destination    Destination   Packet     Byte
           interface      address           port   interface       address               port   count      count
icmp(1)    ge-0/0/1.24    11.11.11.11          0   ge-0/0/0.1      50.50.50.50 dls-monitor(2048) 10000     840

Exactly 10000 packet shown from CLI:

Lets check from cflowd server:

No.     Time            Source       Destination        Protocol Source Port Destination Port Info
5221 01:43:42.764561 172.16.40.1 192.168.150.100       CFLOW    44037       2055             total: 1 (v5) flow
Frame 5221 (114 bytes on wire, 114 bytes captured)
Ethernet II, Src: TeknorMi_5c:3e:9c (00:a0:a5:5c:3e:9c), Dst: Intel_04:fb:7b (00:16:6f:04:fb:7b)
Internet Protocol, Src: 172.16.40.1 (172.16.40.1), Dst: 192.168.150.100 (192.168.150.100)
User Datagram Protocol, Src Port: 44037 (44037), Dst Port: iop (2055)
Source port: 44037 (44037)
Destination port: iop (2055)
Length: 80
Checksum: 0xb6a3 [correct]
Cisco NetFlow/IPFIX
Version: 5
Count: 1
SysUptime: 3200060
Timestamp: Sep 20, 2008 08:52:44.427167000
FlowSequence: 26
EngineType: 188
EngineId: 17
00.. .... .... .... = SamplingMode: No sampling mode configured (0)
..00 0000 0000 0001 = SampleRate: 1
 pdu 1/1
 SrcAddr: 11.11.11.11 (11.11.11.11)
 DstAddr: 50.50.50.50 (50.50.50.50)
NextHop: 10.0.4.13 (10.0.4.13)
InputInt: 117
OutputInt: 60
 Packets: 10000
Octets: 840000
[Duration: 14.110000000 seconds]
SrcPort: 0
DstPort: 2048
padding
TCP Flags: 0x00
Protocol: 1
IP ToS: 0x00
SrcAS: 65412
DstAS: 65412
SrcMask: 32 (prefix: 11.11.11.11/32)
DstMask: 32 (prefix: 50.50.50.50/32)
padding

September 10, 2008

Junos TCPdump

Filed under: Technical section — Tags: — adisubrata @ 12:21 AM

Usually I used TCPdump from shell to capture the the life packet on Junos. Yesterday, I’ve got another TCPdump command from my friend blog, Przemyslaw (Thanks dude). The good thing is, now this command available from cli :)

Here it is:

aragorn@gandalf> monitor traffic interface ge-7/0/0 write-file debug-bgp.cap

You can use wireshark to open the captured file. However, this command is hidden command, so have to type it completely.

July 30, 2008

Installing Junos Bootable on Removable Media (USB/PCMCIA etc)

Filed under: Technical section — adisubrata @ 12:43 AM

This post describes how to fill USB devices with Junos software. In Next Generation RE, upgrade from USB devices is available. You must have at least RE-A-1000 or RE-A-2000 to perform upgrade from USB devices.

Below is the simple manual:

The device name is /dev/rda0 instead of /dev/rad3.
optimus@prime> start shell
Log into directory where the install media file is (ie: /var/tmp/)
optimus@prime% cd <directory>
Issue the following commands:
optimus@prime% dd if=/dev/zero of=/dev/rda0 count=20 ; initialize the media
optimus@prime% dd if=install-media-9.1R2.4-export of=/dev/rda0 bs=64k ;

======

For windows user you can use physdiskwrite Utility.

Additional information:

This bundle is used to produce both the PCMCIA boot flash card and the LS-120 boot floppy
to install jinstall-<release-number>-domestic.tgz.
You must have UNIX super-user privileges in order to issue the "dd" commands.

    * LS-120 boot floppy
      To create an LS-120 boot floppy, ftp the image to the router's /var/tmp directory
      and insert an LS-120 disk into the router's drive.  Then, from the UNIX shell
      on your router, change to the /var/tmp directory and issue the following commands:
            dd if=/dev/zero of=/dev/adf0 count=20
            dd if=install-media-<release-number>-domestic of=/dev/adf0 bs=64k
    * PCMCIA boot flash card
      To create a PCMCIA boot flash card, ftp the image to the router's /var/tmp directory
      and insert a PC card into the routers' drive.  Then, from the UNIX shell on your router,
      change to the /var/tmp directory and issue the following commands:
            dd if=/dev/zero of=/dev/ad3 count=20
            dd if=install-media-<release-number>-domestic of=/dev/ad3 bs=64k 

USB boot storage device:

To create a USB boot storage device, ftp the image to the router's /var/tmp directory and
insert a USB storage device into the router's USB port. Then, from the UNIX shell on your
router, change to the /var/tmp directory and issue the following commands:

dd if=/dev/zero of=/dev/da0 count=20

dd if=install-media-8.3R1.5-domestic of=/dev/da0 bs=64k

June 19, 2008

LDP Traffic Statistic

Filed under: Technical section — Tags: , — adisubrata @ 9:53 PM

Juniper router M-series put the LDP or RSVP prefix into inet.3 tables and label distribution into mpls.0 table. By default, only BGP can access inet.3 table. BGP used inet.3 prefix to map as a next-hop. There is no chance for unicast protocols like OSPF, IS-IS, etc to access inet.3 table.

If we have MPLS clouds which are contain P and PE routers, each PE and P routers connected thru unicast protocols, I.e OSPF, ISIS. So, all traffic coming to PE2 from source address PE1 will be directed through OSPF. No MPLS label needed to forwards those packets.

It’s a bit different to another vendor which is automatically enabling MPLS packets once MPLS turn on. Juniper M-series automatically enabling MPLS label to forwarding VRF traffic to another VRF since the protocols used from PE to PE is BGP.

There are available knobs to moving prefix from inet.3 to inet.0 as shown below:

enugadi@m7i# set protocols mpls traffic-engineering ?
Possible completions:
bgp                  BGP destinations only
bgp-igp              BGP and IGP destinations
bgp-igp-both-ribs    BGP and IGP destinations with routes in both routing tables
mpls-forwarding      Use MPLS routes for forwarding, not routing

This knob above allowing unicast protocols (I.e OSPF, ISIS etc) to use MPLS label.
This label tracing guidance below will use simple topology and moved inet.3 into inet.0 table.

r1: 1.1.1.1/32
r2: 2.2.2.2/32
r3: 3.3.3.3/32
r4: 4.4.4.4/32
r5: 5.5.5.5/32

r1-r2: 10.0.0.0/30
r2-r3: 11.0.0.0/30
r3-r4: 12.0.0.0/30
r4-r5: 13.0.0.0/30

LDP session MUST in Operational State and the connection is OPEN (RFC 3036).

The IGP is OSPF single area.

====================================================
enugadi@m7i# run show route logical-router r1
inet.0: 12 destinations, 16 routes (12 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
1.1.1.1/32         *[Direct/0] 11:34:27
                    > via lo0.1
2.2.2.2/32         *[LDP/9] 03:25:36, metric 1
                    > to 10.0.0.2 via ge-0/0/0.1
                    [OSPF/10] 07:32:26, metric 1
                    > to 10.0.0.2 via ge-0/0/0.1
3.3.3.3/32         *[LDP/9] 03:25:36, metric 1
                    > to 10.0.0.2 via ge-0/0/0.1, Push 299888
                    [OSPF/10] 03:30:55, metric 2
                    > to 10.0.0.2 via ge-0/0/0.1
4.4.4.4/32         *[LDP/9] 03:25:36, metric 1
                    > to 10.0.0.2 via ge-0/0/0.1, Push 299904
                    [OSPF/10] 03:30:55, metric 3
                    > to 10.0.0.2 via ge-0/0/0.1
5.5.5.5/32         *[LDP/9] 01:22:04, metric 1
                    > to 10.0.0.2 via ge-0/0/0.1, Push 299936
                    [OSPF/10] 03:30:55, metric 4
                    > to 10.0.0.2 via ge-0/0/0.1
10.0.0.0/30        *[Direct/0] 11:34:27
                    > via ge-0/0/0.1
                    10.0.0.1/32        *[Local/0] 11:34:27
                    Local via ge-0/0/0.1
11.0.0.0/30        *[OSPF/10] 07:32:26, metric 2
                    > to 10.0.0.2 via ge-0/0/0.1
                    12.0.0.0/30        *[OSPF/10] 03:30:55, metric 3
                    > to 10.0.0.2 via ge-0/0/0.1
13.0.0.0/30        *[OSPF/10] 03:30:55, metric 4
                    > to 10.0.0.2 via ge-0/0/0.1
                    192.168.150.0/24   *[OSPF/10] 03:30:55, metric 3
                    > to 10.0.0.2 via ge-0/0/0.1
224.0.0.5/32       *[OSPF/10] 07:33:16, metric 1
MultiRecv
====================================================
enugadi@m7i# run show ldp session logical-router r1
Address           State        Connection     Hold time
2.2.2.2             Operational  Open             21
====================================================
enugadi@m7i# run show ldp database logical-router r1  <- label received r1
Input label database, 1.1.1.1:0--2.2.2.2:0
Label     Prefix
299872     1.1.1.1/32
3          2.2.2.2/32
299888     3.3.3.3/32
299904     4.4.4.4/32
299920     5.5.5.5/32
Output label database, 1.1.1.1:0--2.2.2.2:0 <- label sent from r1 to r2
Label     Prefix
3          1.1.1.1/32
300016     2.2.2.2/32
300032     3.3.3.3/32
300048     4.4.4.4/32
300064     5.5.5.5/32
====================================================

Traceroute packets from r1 to r5

enugadi@m7i# run traceroute 5.5.5.5 logical-router r1
traceroute to 5.5.5.5 (5.5.5.5), 30 hops max, 40 byte packets
1  10.0.0.2 (10.0.0.2)  1.482 ms  1.146 ms  1.280 ms
MPLS Label=299920 CoS=0 TTL=1 S=1
2  11.0.0.2 (11.0.0.2)  1.309 ms  1.180 ms  1.193 ms
MPLS Label=300128 CoS=0 TTL=1 S=1
3  12.0.0.2 (12.0.0.2)  1.360 ms  1.238 ms  1.343 ms
MPLS Label=299968 CoS=0 TTL=1 S=1
4    5.5.5.5 (5.5.5.5)  1.199 ms  1.231 ms  1.146 ms

Router r1 push label 299920 on the packet destination to r5.
Let’s we check the label assignment in the router r1.

enugadi@m7i# run show ldp path 5.5.5.5 logical-router r1
Output Session (label)          Input Session (label)
2.2.2.2:0(300064)               2.2.2.2:0(299920)
Attached route:  5.5.5.5/32, Ingress route

Let’s we check the swap label in the r2 router:

enugadi@m7i# run show route table mpls.0 logical-router r2 | find 299920
299920             *[LDP/9] 01:08:29, metric 1
                    > to 11.0.0.2 via ge-0/0/0.2, Swap 300128

Router r2 swaps the label 299920 to 300128. It matches with packet no.2.

Lets do and check label swapping in the router r4.

enugadi@m7i# run show route table mpls.0  | find 300128
300128             *[LDP/9] 01:10:07, metric 1
                    > to 12.0.0.2 via ge-0/0/2.0, Swap 299968

Router R4 swaps the label 300128 to 299968. It matches with the packet no.4.

Lets check what r4 done to packet with label 299968

enugadi@m7i# run show route table mpls.0 logical-router r4 | find 299968
299968             *[LDP/9] 01:11:43, metric
                    > to 13.0.0.2 via ge-0/0/0.5, Pop

As expected, router r4 do POP label.

LDP you can detect and monitoring amount of traffic to specific destination.
It’s called with traffic-statistic knob, which is available under protocols ldp stanza.

enugadi@m7i# show protocols ldp
traceoptions {
file ldp;
flag label detail;
flag path detail;
}
traffic-statistics { <- this one
file ldp-stats;
interval 60;
}
interface ge-0/0/1.2;
interface ge-0/0/2.0;
interface lo0.0;

You will need to enable this knobs in the transit router, usually on P routers.

enugadi@m7i# run show ldp traffic-statistics
FEC                  Type                Packets              Bytes    Shared
1.1.1.1/32          Transit                   0                  0    No
Ingress                   0                  0    No
2.2.2.2/32          Transit                   0                  0    No
Ingress                   6                480    No
4.4.4.4/32          Transit                   0                  0    No
Ingress                   3                258    No
5.5.5.5/32          Transit                   0                  0    No
Ingress                   0                  0    No

Do ping from r1 (1.1.1.1) to r5 (5.5.5.5) and monitor the traffic in the transit LSR r3.

enugadi@m7i# run ping 5.5.5.5 logical-router r1 source 1.1.1.1 rapid count 1000
PING 5.5.5.5 (5.5.5.5): 56 data bytes
!!!!!!!!!!!!!!!!!!! — snipped —-
— 5.5.5.5 ping statistics —
1000 packets transmitted, 1000 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.076/1.345/14.311/1.073 ms
enugadi@m7i# run show ldp traffic-statistics
FEC                  Type                Packets              Bytes    Shared
1.1.1.1/32          Transit                1000              88000    No
Ingress                   0                  0    No
2.2.2.2/32          Transit                   0                  0    No
Ingress                  16               1090    No
4.4.4.4/32          Transit                   0                  0    No
Ingress                   8                608    No
5.5.5.5/32          Transit                1000              88000    No
Ingress                   0                  0    No

As shown, traffic statistic indicates the traffic from 1.1.1.1 to 5.5.5.5 is 1000 packets.

Let’s try another packet, send icmp packets from r1 to r4.

enugadi@m7i# run ping 4.4.4.4 logical-router r1 source 1.1.1.1 rapid count 1000
PING 4.4.4.4 (4.4.4.4): 56 data bytes
!!!!!!!!!!!!!!!!!!! — snipped —-
— 4.4.4.4 ping statistics —
1000 packets transmitted, 1000 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.083/1.351/44.441/1.722 ms

[edit]
enugadi@m7i# run show ldp traffic-statistics
FEC                  Type                Packets              Bytes    Shared
1.1.1.1/32          Transit                2000             176000    No
Ingress                   0                  0    No
2.2.2.2/32          Transit                   0                  0    No
Ingress                  37               2362    No
4.4.4.4/32          Transit                1000              88000    No
Ingress                  18               1308    No
5.5.5.5/32          Transit                1000              88000    No
Ingress                   0                  0    No

The packet recorded in the r3 is 1000 to FEC 4.4.4.4.

There is available SNMP OID to map these results and put into nms station.

enugadi@m7i# run show snmp mib walk jnxLdpTransitPackets
jnxLdpTransitPackets.1.1.4.1.1.1.1.32 = 2000
jnxLdpTransitPackets.1.1.4.2.2.2.2.32 = 0
jnxLdpTransitPackets.1.1.4.4.4.4.4.32 = 1000
jnxLdpTransitPackets.1.1.4.5.5.5.5.32 = 1000

[edit]
enugadi@m7i# run show snmp mib walk jnxLdpTransitOctet
Request failed: Could not resolve ‘jnxLdpTransitOctet’ to an OID

[edit]
enugadi@m7i# run show snmp mib walk jnxLdpTransitOctets
jnxLdpTransitOctets.1.1.4.1.1.1.1.32 = 176000
jnxLdpTransitOctets.1.1.4.2.2.2.2.32 = 0
jnxLdpTransitOctets.1.1.4.4.4.4.4.32 = 88000
jnxLdpTransitOctets.1.1.4.5.5.5.5.32 = 88000

[edit]
enugadi@m7i# run show snmp mib walk jnxLdpStatsEntry
jnxLdpFecStatisticsStatus.1.1.4.1.1.1.1.32 = 1
jnxLdpFecStatisticsStatus.1.1.4.2.2.2.2.32 = 1
jnxLdpFecStatisticsStatus.1.1.4.4.4.4.4.32 = 1
jnxLdpFecStatisticsStatus.1.1.4.5.5.5.5.32 = 1
jnxLdpIngressOctets.1.1.4.1.1.1.1.32 = 0
jnxLdpIngressOctets.1.1.4.2.2.2.2.32 = 4140
jnxLdpIngressOctets.1.1.4.4.4.4.4.32 = 2358
jnxLdpIngressOctets.1.1.4.5.5.5.5.32 = 0
jnxLdpIngressPackets.1.1.4.1.1.1.1.32 = 0
jnxLdpIngressPackets.1.1.4.2.2.2.2.32 = 66
jnxLdpIngressPackets.1.1.4.4.4.4.4.32 = 33
jnxLdpIngressPackets.1.1.4.5.5.5.5.32 = 0
jnxLdpTransitOctets.1.1.4.1.1.1.1.32 = 176000
jnxLdpTransitOctets.1.1.4.2.2.2.2.32 = 0
jnxLdpTransitOctets.1.1.4.4.4.4.4.32 = 88000
jnxLdpTransitOctets.1.1.4.5.5.5.5.32 = 88000
jnxLdpTransitPackets.1.1.4.1.1.1.1.32 = 2000
jnxLdpTransitPackets.1.1.4.2.2.2.2.32 = 0
jnxLdpTransitPackets.1.1.4.4.4.4.4.32 = 1000
jnxLdpTransitPackets.1.1.4.5.5.5.5.32 = 1000

« Newer PostsOlder Posts »

Blog at WordPress.com.