[Xorp-users] Fwd: tests conformance using XORP

Pavlin Radoslavov pavlin at icir.org
Mon Dec 10 11:24:05 PST 2007


See comments inline.

> interfaces {
>     restore-original-config-on-shutdown: false
>     interface eth0 {
>     description: "data interface"
>     disable: false
>     /* default-system-config */
>      vif eth0 {
>             disable: false
>             address 192.168.7.5 {
>                 prefix-length: 24
>                 broadcast: 192.168.7.255
>                 disable: false
>         }
>     }
>     }
> 
>   interface eth1 {
>     description: "data interface"
>     disable: false
>     /* default-system-config */
>      vif eth1 {
>             disable: false
>             address 192.168.8.5 {
>                 prefix-length: 24
>                 broadcast: 192.168.8.255
>                 disable: false
>         }
>     }
> 
>  }
> 
> }

<DEL>

> protocols {
>     static {
> 
>     interface-route 192.168.8.0/24 {
>      next-hop-interface: "eth0"
>      next-hop-vif: "eth0"
>      next-hop-router: 192.168.7.5
>      metric: 1
>      }
> 
>     mrib-interface-route 192.168.8.0/24 {
>      next-hop-interface: "eth0"
>      next-hop-vif: "eth0"
>      metric: 1
>      }

Few things about the above static routers configuration:

* The "interface-route" and "mrib-interface-route" entries are
  needed in special cases when you want to force the route to point
  toward a specific interface even if the next-hop router's IP
  address doesn't belong to the same subnet.
  If you want to use static routes, in your setup it is better to
  use the "route" and "mrib-route" configuration statements instead.

* In the interface-route statement above you have set the
  next-hop-router to the eth0's IP address which is probably not
  what you want.

* Typically the "mrib-route" or "mrib-interface-route" should be
  used if you want to add multicast-specific entries that are used
  for multicast RPF check only, but are not used by the unicast
  routing.
  In your case probably you don't need them to be different, so for
  simplicity you might want to remove the "mrib-" static route
  entry.

* The particular static routes are for the 192.168.8.0/24 subnet
  which actually is the subnet of interface eth1.
  You cannot overwrite the routes for directly connected subnets so
  you shouldn't add such routes.

Said that, if you want to add a static route for a non-directly
connected subnet (say, 192.168.6.0/24), it should look like:

    route 192.168.6.0/24 {
        next-hop: 192.168.7.20
    }

where I assume that 192.168.7.20 is the next-hop router toward
the destination.

> 
>     }
> 
> }
> 
> 
> 
> policy {
>     /* Describe connected routes for redistribution */
>     policy-statement connected {
>     term export {
>         from {
>         protocol: "connected"
>         }
>     }
>     }
> }
> 
> 
> policy {
>     /* Describe static routes for redistribution */
>     policy-statement static {
>         term export {
>             from {
>                 protocol: "static"
>             }
>         }
>     }
> }

<DEL>

> protocols {
>     rip {
> 
> /* Connected interfaces will only be advertised if explicitly exported */
>         export: "connected"
>     export: "static"

If you want to export both "connected" and "static", then you should
add them with the same export statement. E.g.:
    export: "connected,static"

If you have two "export" statements, the second one will overwrite
the first one.

> /* Run on specified network interface addresses */
>         interface eth0 {
>             vif eth0 {
>                 address 192.168.7.5 {
>                     disable: false
>                 }
>             }
>         }
> 
>     interface eth1 {
>             vif eth1 {
>                 address 192.168.8.5 {
>                     disable: false
>                 }
>             }
>         }
> 
>     }
> }

<DEL>

> protocols {
>     pimsm4 {
>     disable: false
>     interface eth0 {
>         vif eth0 {
>         disable: false
>         /* enable-ip-router-alert-option-check: false */
>         /* dr-priority: 1 */
>         /* hello-period: 30 */
>         /* hello-triggered-delay: 5 */
>         /* alternative-subnet 10.40.0.0/16 */
>         }
>     }
> 
>     interface eth1 {
>         vif eth1 {
>         disable: false
>         /* enable-ip-router-alert-option-check: false */
>         /* dr-priority: 1 */
>         /* hello-period: 30 */
>         /* hello-triggered-delay: 5 */
>         /* alternative-subnet 10.40.0.0/16 */
>         }
>     }
> 
>     interface register_vif {
>         vif register_vif {
>         /* Note: this vif should be always enabled */
>         disable: false
>         }
>     }
> 
>       /*     static-rps {*/
>     /*    rp 192.168.7.5 {*/
>     /*    group-prefix 224.0.0.0/4 {*/
>             /* rp-priority: 192 */
>             /* hash-mask-len: 30 */
>     /*    } */
>     /*    } */
> /*    } */
> 
>     bootstrap {
>         disable: false
>         cand-bsr {
>         scope-zone 224.0.0.0/8 {
>             /* is-scope-zone: false */
>             cand-bsr-by-vif-name: "eth0"
>             /* cand-bsr-by-vif-addr: 10.10.10.10 */
>              bsr-priority: 1
>             /* hash-mask-len: 30 */
>         }
>           }
>         cand-bsr {
>         scope-zone 224.0.0.0/8 {
>             /* is-scope-zone: false */
>             cand-bsr-by-vif-name: "eth1"
>             /* cand-bsr-by-vif-addr: 10.10.10.10 */
>              bsr-priority: 2
>             /* hash-mask-len: 30 */
>         }
> 
>         }
> 
>         cand-rp {
>         group-prefix 224.0.0.0/8 {
>             /* is-scope-zone: false */
>             cand-rp-by-vif-name: "eth0"
>             /* cand-rp-by-vif-addr: 10.10.10.10 */
>              rp-priority: 192
>             /* rp-holdtime: 150 */
>         }
>         }
>             cand-rp {
>         group-prefix 224.0.0.0/8 {
>             /* is-scope-zone: false */
>             cand-rp-by-vif-name: "eth1"
>             /* cand-rp-by-vif-addr: 10.10.10.10 */
>              rp-priority: 195
>             /* rp-holdtime: 150 */
>         }
>         }
> 
> 
>     }

It appears that you have decided to use the dynamic Bootstrap
mechanism instead of static RPs. You should know that on startup it
can take up to 2-3 minutes or so until the Bootstrap election is
completed and the Cand-RP set has converged.
For testing purpose you might want to use a static RP so you can
avoid the startup delay.
There is nothing wrong with using the Bootstrap mechanism, and if
you deal only with (S,G) Joins then the RPs are not used, but you
should be aware of the startup delay.

Also, you might want to use 224.0.0.0/4 prefix to cover the whole
multicast address space (in case you decide to use multicast with
some group addresses that are outside the 224.0.0.0/8 prefix).

>     switch-to-spt-threshold {
>         /* approx. 1K bytes/s (10Kbps) threshold */
>         disable: false
>         interval: 100
>         bytes: 102400
>     }
> 
>     traceoptions {
>         flag all {
>         disable: false
>         }
>     }
>     }

<DEL>

> __________________________________________
> 
> root at thiago> show pim join
> Group           Source          RP              Flags
> 224.1.1.1       192.168.6.1     192.168.8.5     SG
>     Upstream interface (S):    UNKNOWN
                                 ~~~~~~~
>     Upstream interface (RP):   register_vif
>     Upstream MRIB next hop (RP): UNKNOWN
>     Upstream MRIB next hop (S):  UNKNOWN
                                   ~~~~~~~
>     Upstream RPF'(S,G):        UNKNOWN
                                 ~~~~~~~

The real reason that the (S,G) Join wasn't originated by the XORP
router is because the next-hop toward S (192.168.6.1) is unknown.
In your configuration there isn't a static route toward that
destination, so the route should come from the dynamic protocol (RIP
in your case).
It appears that the route is not received by RIP. You could verify
that by running the "show route table ipv4 unicast rip" xorpsh
command.
If you are using same multiple "export" statements in all XORP
routers, then probably none of them is advertising its connected
routes.

Though, again for testing purpose you might want just to use static
routes so you will avoid the extra startup delay with the dynamic
routing protocols.

After you apply the above fixes, use the "show pim join" command to
make sure that the upstream information is received correctly by the
PIM-SM module.

Regards,
Pavlin

>     Upstream state:            Joined
>     Join timer:                48
>     KAT(S,G) running:          false
>     Local receiver include WC: ...
>     Local receiver include SG: ...
>     Local receiver exclude SG: ...
>     Joins RP:                  ...
>     Joins WC:                  ...
>     Joins SG:                  O..
>     Join state:                O..
>     Prune state:               ...
>     Prune pending state:       ...
>     I am assert winner state:  ...
>     I am assert loser state:   ...
>     Assert winner WC:          ...
>     Assert winner SG:          ...
>     Assert lost WC:            ...
>     Assert lost SG:            ...
>     Assert lost SG_RPT:        ...
>     Assert tracking SG:        O..
>     Could assert WC:           ...
>     Could assert SG:           ...
>     I am DR:                   O.O
>     Immediate olist RP:        ...
>     Immediate olist WC:        ...
>     Immediate olist SG:        O..
>     Inherited olist SG:        O..
>     Inherited olist SG_RPT:    ...
>     PIM include WC:            ...
>     PIM include SG:            ...
>     PIM exclude SG:            ...
>  (END)



More information about the Xorp-users mailing list