[Xorp-users] Fwd: Fwd: tests conformance using XORP
Jeandro de M. Bezerra
jeandro at larces.uece.br
Fri Dec 21 14:43:22 PST 2007
---------- Forwarded message ----------
From: Jeandro Bezerra <jeandro at gmail.com>
Date: 21/12/2007 19:41
Subject: Re: [Xorp-users] Fwd: tests conformance using XORP
To: Pavlin Radoslavov <pavlin at icir.org>
Cc: xorp-users at xorp.org, Laure Waha Mendouga <laure18 at gmail.com>
First of all, thank you for the answers
but i am with problems in the RIP. In the show pim join output
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
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: ...
The source 192.168.6.1 is generated by TEE (another router).
It appears that the route is not received by RIP. You could verify
that by running the "show route table ipv4 unicast rip". I do not show nothing.
I am attached my config.boot. Can you help me in my rip configuration?
Thanks
2007/12/10, Pavlin Radoslavov < pavlin at icir.org>:
>
> 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)
>
--
Jeandro de Mesquita Bezerra, MSc
Professor Substituto - Universidade Estadual do Ceará (UECE)
Professor Auxiliar - UNICE-Ensino Superior
jeandro(arroba/at)larces.uece.br
LARCES-Laboratório de Redes de Comunicação e Segurança da Informação.
--
Jeandro de Mesquita Bezerra, MSc
Professor Substituto - Universidade Estadual do Ceará (UECE)
Professor Auxiliar - UNICE-Ensino Superior
jeandro(arroba/at)larces.uece.br
LARCES-Laboratório de Redes de Comunicação e Segurança da Informação.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20071221/7140470b/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: config.boot
Type: application/octet-stream
Size: 8355 bytes
Desc: not available
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20071221/7140470b/attachment-0001.obj
More information about the Xorp-users
mailing list