RE: IPv4 Multicast

2010-05-31 Thread Rens 
Something weird today when I did some more tests today...

When I configured a subinterface with the: ip pim sparse-mode

 (config)#int GigabitEthernet 3/0.310
 (config-subif)#ip pim sparse-mode 
May 31 15:48:40.218 CET: %PIM-5-DRCHG: DR change from neighbor 0.0.0.0 to
10.11.130.1 on interface GigabitEthernet3/0.310

At that point all my L2TPv3 tunnels on the other subinterfaces on Gi3
stopped working.
When I removed the command, everything came back up again.

Is this a bug or am I missing something?

Regards,

Rens

-Original Message-
From: Rens [mailto:r...@autempspourmoi.be] 
Sent: mercredi 26 mai 2010 16:59
To: 'Everton Marques'
Cc: nanog@nanog.org; 'Jamie Sobczyk'
Subject: RE: IPv4 Multicast

One more question:

If I would now connect another switch (WS-C3524-XL) between the VLC receiver
and the 3560G like this:

VLC receiver - 3524XL - 3560G - 1841 - 1841 - 4503 - VLC sender

That 3524XL only supports CGMP, what do I need to change on the config to
not broadcast this multicast traffic?

Do I need to configure the ip cgmp router-only on the 1841 at Receiver?

-Original Message-
From: Rens [mailto:r...@autempspourmoi.be] 
Sent: mercredi 26 mai 2010 16:10
To: 'Everton Marques'
Cc: nanog@nanog.org; 'Jamie Sobczyk'
Subject: RE: IPv4 Multicast

Woot! It was the TTL on the VLC sender that was on default, changed it to 10
and now and I have my video.

 

Thanks for your help.

  _  

From: Everton Marques [mailto:everton.marq...@gmail.com] 
Sent: mercredi 26 mai 2010 15:42
To: Rens
Cc: Jamie Sobczyk; nanog@nanog.org
Subject: Re: IPv4 Multicast

 

Does "show ip mroute count" on the 1841 (RP) display activity on traffic
counters?

 

Is the VLC sender directing multicast to the 1841 (RP) thru a default route?

 

Is the VLC sender issuing multicast packets with a high-enough multicast TTL
?

 

Everton

 

On Wed, May 26, 2010 at 10:21 AM, Rens  wrote:

I have all those things you mentioned below.
The VLC server (10.0.1.2) sends out 2 streams on 239.255.0.1 & 239.255.0.2
I see both in SAP, when I try to join 239.255.0.2, nothing happens in VLC
and below you have the output of my routers & switches at that time:

On my RP router I see for show ip mroute:

(*, 239.255.255.255), 5d04h/00:03:26, RP 172.16.0.2, flags: SJCL

 Incoming interface: Null, RPF nbr 0.0.0.0
 Outgoing interface list:

   FastEthernet0/1, Forward/Sparse, 1d06h/00:03:26
   FastEthernet0/0.200, Forward/Sparse, 5d04h/00:02:41

(10.0.1.2, 239.255.255.255), 1d06h/00:03:28, flags: LT
 Incoming interface: FastEthernet0/0.200, RPF nbr 0.0.0.0
 Outgoing interface list:
   FastEthernet0/1, Forward/Sparse, 1d06h/00:03:26

(*, 239.255.0.2), 00:01:10/00:03:19, RP 172.16.0.2, flags: S

 Incoming interface: Null, RPF nbr 0.0.0.0
 Outgoing interface list:

   FastEthernet0/1, Forward/Sparse, 00:01:10/00:03:19

(*, 239.255.255.250), 00:07:19/00:03:07, RP 172.16.0.2, flags: S

 Incoming interface: Null, RPF nbr 0.0.0.0
 Outgoing interface list:

   FastEthernet0/1, Forward/Sparse, 00:07:22/00:03:03

(*, 239.195.255.255), 1d06h/00:02:39, RP 172.16.0.2, flags: S

 Incoming interface: Null, RPF nbr 0.0.0.0
 Outgoing interface list:

   FastEthernet0/1, Forward/Sparse, 00:01:24/00:02:39

(*, 224.2.127.254), 5d04h/00:03:10, RP 172.16.0.2, flags: SJCL

 Incoming interface: Null, RPF nbr 0.0.0.0
 Outgoing interface list:

   FastEthernet0/1, Forward/Sparse, 1d06h/00:03:10
   FastEthernet0/0.200, Forward/Sparse, 5d04h/00:02:38

(*, 224.0.1.40), 5d04h/00:02:40, RP 172.16.0.2, flags: SJCL

 Incoming interface: Null, RPF nbr 0.0.0.0
 Outgoing interface list:

   FastEthernet0/1, Forward/Sparse, 1d06h/00:02:59
   FastEthernet0/0.200, Forward/Sparse, 5d04h/00:02:40

On my other router I have:

(*, 239.255.255.255), 5d04h/stopped, RP 172.16.0.2, flags: SJCL
 Incoming interface: FastEthernet0/1, RPF nbr 192.168.0.2
 Outgoing interface list:
   FastEthernet0/0.200, Forward/Sparse, 5d04h/00:02:54

(10.0.1.2, 239.255.255.255), 1d06h/00:02:58, flags: LJT
 Incoming interface: FastEthernet0/1, RPF nbr 192.168.0.2
 Outgoing interface list:
   FastEthernet0/0.200, Forward/Sparse, 1d06h/00:02:54

(*, 239.255.0.2), 00:01:55/00:02:56, RP 172.16.0.2, flags: SJC
 Incoming interface: FastEthernet0/1, RPF nbr 192.168.0.2
 Outgoing interface list:
   FastEthernet0/0.200, Forward/Sparse, 00:01:55/00:02:56

(*, 239.255.255.250), 00:08:04/00:02:53, RP 172.16.0.2, flags: SJC
 Incoming interface: FastEthernet0/1, RPF nbr 192.168.0.2
 Outgoing interface list:
   FastEthernet0/0.200, Forward/Sparse, 00:08:04/00:02:53

(*, 239.195.255.255), 5d04h/00:02:50, RP 172.16.0.2, flags: SJC
 Incoming interface: FastEthernet0/1, RPF nbr 192.168.0.2
 Outgoing interface list:
   FastEthernet0/0.200, Forward/Sparse, 00:02:08/00:02:50

(*, 224.2.127.254), 5d04h/00:02:48, RP 172.16.0.2, flags: SJCL
 Incoming interface: FastEthernet0/1, RPF nbr 192.168.0.2
 Outgoing interface list:
   FastEthernet0/0.200, Forward/Sparse, 5d04h/00:02:48

(*, 224.0.1.40), 5d04h/00:02:52, RP 172.16.0.2, flags:

Re: Junos Asymmetric Routing

2010-05-31 Thread Richard A Steenbergen 
On Sun, May 30, 2010 at 10:16:14AM -0700, Kevin Oberman wrote:
> 
> I remember a posting to this list back in the late 90s from Tony Li,
> who knows a bit about BGP. He urged that multi-hop BGP never be used
> and pointed out that it had not been intended for use except as a test
> tool, not a production one and should have been stripped from IOS
> before it was shipped.
> 
> While there are a few good cases for using it, it is generally a bad,
> bad idea. And this thread demonstrates that he had reason for the
> warning

I think you guys may be getting a tad carried away with the crusade
against multihop BGP. The only thing you're really giving up when you
use it is liveness detection, which as we all know BGP is actually
pretty terrible at implementing anyways (hows that 180 sec IOS default
working out for you?). There are much better mechanisms out there, like
BFD, which could be used to provide better liveness detection to BGP
through nexthop invalidation. 

I'm not saying everyone should run out and do all their peering over
multihop EBGP without carefully considering a replacement for the
liveness detection component, I just hate it when people get religious
about such a simple concept for no good reason (well, other than Randy
Bush getting to do his best Andy Rooney impersonation :P). Multihop BGP
is no more evil than anything else we do with the Internet, and the fact
that we've all managed to use it successfully for IBGP proves that it
can work out just fine. There are some pretty interesting things you can
accomplish as far as large scale traffic engineering if you can free
yourself from the requirement of speaking EBGP with a directly connected
neighbor, processed by whatever slow overpriced router CPU could be
stuffed into that box. Again, I just hate to see the concepts dismissed
out of hand because of some old BGP ideology about a problem that can be
addressed any number of other ways.

-- 
Richard A Steenbergenhttp://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)