Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Reducing Usenet Bandwidth

  • From: Stephen Griffin
  • Date: Mon Feb 04 01:18:35 2002

In the referenced message, Jared Mauch said:
<snip>
> 	I don't take any immediate offense but the number of
> multicast connected sites is (slowly) going up.  Sprint customers
> can toggle their (bgp) session from nlri unicast -> unicast multicast
> in order to get mbgp routes and enable pim to do forwarding.  Obviously
> one needs to chat with someone to get msdp going.
> 
> 	The routers don't tend to have very multicast related bugs anymore,
> it's all people who can't configure their routers.
> 
> 	Of the 100+ sessions that are in sdr/sap these days I can typically
> reach (at least) 65%+ of them without any problems.
> 
> 	The problem is that the "tier 2" and whatnot providers have [mostly]
> missed the boat on it and don't have people that are able to configure
> their routers for mbgp.  (this is not to say all but most).
> 
> 	There are a lot of resources for getting help in fixing and
> deploying multicast these days.  It'd be nice to see more people turning it
> on.
> 
> 	- Jared

I'm wondering how may folks are having issues with the oddities related
to Cisco doing RPF checks based on administrative distance, rather than
longest-match against the MRIB. With this, a shorter EBGP-learned route
wins out over a longer IBGP-learned route.

I know it is possible to turn on (via undocumented command) longest-match.
But, it still matches across both the URIB and MRIB equally, such that
a longer unicast prefix wins over a shorter multicast prefix.

Ideally, the RPF checks would be longest-match against the MRIB first,
and falling back to longest-match against the URIB (which is exactly
what the MSDP RPF checks presently do.)

I find it really weird when the "sh ip rpf" lists an ebgp-unicast
route as the rpf source, when an ibgp-multicast route
is available. Essentially makes even exchanging multicast nlri somewhat
pointless, when it is disregarded frequently.

The workaround I've been suggested to use is the undocumented command
and lots of static mroutes (to beat out unicast bgp), whenever problems
surface.





Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.