Monday, August 01, 2022

Re: mpls and pf

Hi


my phsical environment are 4 boxes

2 are juniper srx they do the core routing in the back.

2 openbsd boxes  , on is my main firewall the other one is for the
opposite side.

both connetcted to an l2 switch .


obsd1 em0 connect to srx1

obsd1 em1 connect to srx2

obsd2 em0 connect to srx1

obsd2 em1 connect to srx2

srx1 connect to srx2


on my obsd1 box are the em0 and the em1 interface located in a vrf 20

also the ldpd , opsfd , the mpw0 if and the bgpd

the bridge for the mpw0 ist in rdomain 0


an default gw interface vether20 for rdomain 20

rdomain 20
inet 172.16.99.1/32
-inet6

!/sbin/route -n -T 20 add default 172.16.99.1
up


/etc 32>cat hostname.em0
rdomain 20
-inet6
mtu 1574
mpls
inet 172.16.12.2/30
up

/etc 33>cat hostname.em1
rdomain 20
-inet6
mtu 1574
mpls
inet 172.16.13.6/30
up

/etc 34>cat hostname.bridge100
add mpw0
add vlan100
up

/etc 35>cat hostname.mpw0
tunneldomain 20
up

the is also an vxlan to connect 2 vlans ( at this veb are also connected
an vm )

/etc 36>cat hostname.vxlan120
rdomain 60
tunneldomain 20
tunnelttl 5
tunnel 172.16.2.251 172.16.2.252 vnetid 120
up


for the rdomain 20 i have an anchor at the first position of my pf.conf.

/etc 39>cat fw/backbone.cf
#pass out quick on vether20 inet from any to 224.0.0.0/24 no state

anchor dns {
pass in quick on { em0,em1 } inet proto udp from any to any port 53
rtable 0 \
        rdr-to 127.0.0.1 port 9953 \
        keep state ( udp.first 30, udp.single 15, udp.multiple 30 )

}
anchor ntp {
pass in quick on { em0,em1} inet proto udp from any to any port 123
rtable 0 \
        rdr-to 127.0.0.1 port 123 \
        keep state ( udp.first 30, udp.single 15, udp.multiple 30 )
}

pass out quick on vether20 inet from <backbone> to <local-networks>
rtable 0 nat-to (lan)
pass out quick on vether20 inet from <backbone> to ! <local-networks>
rtable 40 nat-to (pppoe0)


#pass quick on { em0 , em1 } mpls
pass quick on { em0 , em1 , lo1 } no state

the opposite side of obsd1 , obsd2 have the same configuration but
without the rdomain 20

so it means , all daemons are running at rdom 0


from routing perspectiv everthing work if the em0 , em1 interface at the
obsd1 box , are in set skip on rule at

pf.conf


this works also after an reboot.


if i remove the interfaces em0 , em1 from set skip to

the mpls ( mpw0 ) are not coming up obsd2 can't discover obsd1


put i the interface back to "set skip on" to everthing are coming up.


if i remove the interface from skip to , without booting and the mpls was up

then i see that my rules are matching , and the l2vpn ( mpw0 ) are keep
running / up.


i hope my explanation are not to ugly to understand.


holger






On 01.08.22 12:42, Peter Nicolai Mathias Hansteen wrote:
>
>> 1. aug. 2022 kl. 09:36 skrev Holger Glaess <glaess@glaessixs.de>:
>>
>> hi,
>>
>>
>> i have a small issue with mpls .
>>
>> if i do an set skip on "em0 em1" in my pf.conf
>>
>> the mpls network is working.
>>
>>
>> i see my mpls neighbor for mpw ( ldpctl sh disco )
>>
>>
>> if i do only a "pass quick on { em0,em1 } no state"
>>
>> they don't show the mpls neigbor but the rule match.
>>
>>
>> is there a possebility to do an kind of
>>
>> pass quick on { em0 , em1 } mpls ?
>>
>>
>> how can i handle correct mpls with pf ?
> I have zero hands on experience with mpls, but since
>
> [Mon Aug 01 12:35:07] peter@skapet:~$ apropos mpls
> mpe(4) - MPLS Provider Edge
> mpip(4) - MPLS IP layer 2 pseudowire
> mpw(4) - MPLS Ethernet pseudowire
>
> turns up configurable interfaces tied to mpls and filtering in PF usually involves interfaces in some way or the other, you might want to go in the direction of setting one or more of those, depending on what your configuration looks like.
>
> I hope this is at least a little helpful. And it would be nice for all of us to hear back when you get things working. When you do report back, please leave in as much detail as possible but if necessary anonymize by using RFC5737 addresses instead of the real ones.
>
> All the best,
> Peter
>
>
> —
> Peter N. M. Hansteen, member of the first RFC 1149 implementation team
> http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
> "Remember to set the evil bit on all malicious network traffic"
> delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
>
>
>
>

No comments:

Post a Comment